puppeteer/.eslintignore

assets/
build/
coverage/
doclint/
lib/
test-ts-types/
tsconfig.tsbuildinfo
vendor/
chore: use `composite` builds for tests (#8522) 2022-06-15 10:05:25 +00:00			`assets/`
			`build/`
			`coverage/`
			`doclint/`
chore: move code to src/ and emit with TypeScript (#5568) This updates our `tsconfig.json` so it emits our JavaScript files as well as type checking them. We compile into `./lib` which we then ship in our npm package. The source code has moved from `./lib` into `./src`. Because the `src/` directory is exclusively JS files, this change is a no-op in terms of code functionality but is the first step towards being able to replace `src/X.js` with `src/X.ts` in a way that allows us to migrate incrementally. The `lib` directory is gitignored, and the `src` directory is npmignored. On `npm publish` we will now run `npm run tsc` in order to generate the outputted code. 2020-04-02 14:25:19 +00:00			`lib/`
fix: wider compat TS types and CI checks to ensure correct type defs (#6855) * fix: wider compat TS types and CI checks to ensure correct type defs This PR improves our TS types further to make sure they are usable in a TS environment where ES Modules are the target output. Our use of `export =` is problematic this environment as TypeScript does not allow `export =` to be used and it errors. The fix for the type issues to avoid `export =` is to instead define the functions that you gain access to when you import Puppeteer as top level functions in our `types.d.ts` file. We can do this by declaring them explicitly in `src/node.ts`. These are then rolled into `lib/types.d.ts` at build time. The downside to this is that we have to keep those declarations in sync with the Puppeteer API; should we add a new method to the `Puppeteer` class, we must add it to the `nodes.ts` declarations. However, this could easily be automated by a small script that walks the AST and generates these. I will do that in a follow-up PR, but I consider this low risk given how rarely the very top level API of Puppeteer changes. The nice thing about this approach is we no longer need our script that hacks on changes to `lib/types.d.ts`. To avoid yet more releases to fix issues in one particular TS environment, this PR also includes a suite of example setups that we test on each CI run. Each sample folder contains `good.ts`, which should have no TS errors, and `bad.ts`, which should have some errors. The test first packs Puppeteer into a tar, and then installs it from that tar into each project. This should replicate how the published package behaves when it is installed. We then check that we get no errors on `good.ts`, and the expected errors on `bad.ts`. We have a variety of test projects that cover both TS and JS source code, and CJS and ESM imports and outputs. 2021-02-10 12:04:36 +00:00			`test-ts-types/`
chore: use `composite` builds for tests (#8522) 2022-06-15 10:05:25 +00:00			`tsconfig.tsbuildinfo`
			`vendor/`