Commit Graph

14 Commits

Author SHA1 Message Date
jrandolf
a3db064cbb
chore: update dependencies (#10785) 2023-08-28 13:01:52 +02:00
Nikolay Vitkov
88439f913e
fix: update the target to ES2022 (#10574) 2023-07-18 18:28:03 +02:00
Nikolay Vitkov
031b021703
chore: bump TS target to ES2021 (#10247) 2023-05-26 07:37:05 +00:00
Nikolay Vitkov
070ee03d31
chore: network module for BiDi (#10159) 2023-05-22 14:52:31 +02:00
jrandolf
2ba96c6557
Revert "refactor: update TypeScript to ES2022" (#10184) 2023-05-15 11:37:41 +02:00
jrandolf
db87ae65e1
refactor: update TypeScript to ES2022 (#10182) 2023-05-15 11:24:23 +02:00
jrandolf
f42336cf83
feat: separate puppeteer and puppeteer-core (#9023)
This PR moves the puppeteer source code into separate mono-repo packages:

- `puppeteer` and `puppeteer-core` are now separated into their own
packages.
- `puppeteer-core` has a new exports called `puppeteer-core/internal`
for internal usage.

Tests and various tools have been updated to accommodate the migration.
2022-10-05 14:17:03 +02:00
jrandolf
b4e751f29c
feat: use strict typescript (#8401) 2022-05-31 16:34:16 +02:00
Jack Franklin
8340cb7c34
chore: set module to esnext in tsconfig.json (#7256)
The main `tsconfig.json` file is only used for API Extractor, and by VSCode to provide type information. It is _not_ used to compile Puppeteer for shipping. Therefore we can specify `module: "esnext"` in here so that VSCode knows we can use all the latest and greatest module features (primarily, dynamic imports). In `tsconfig.cjs.json` and `tsconfig.esm.json` we set the `module` setting for CJS/ESM respectively.
2021-05-21 10:05:41 +00:00
Mathias Bynens
97c9fe2520
chore: drop support for Node.js 10 (#7200)
This is a prerequisite for shipping Puppeteer as JavaScript modules.

Issue: #6753

BREAKING CHANGE: Node.js 10 is no longer supported.
2021-05-17 11:34:58 +02:00
Jack Franklin
ebd087a316
feat(types): expose typedefs to consumers (#6745)
This PR replaces https://github.com/puppeteer/puppeteer/pull/6289 with a simpler approach to types where we compile them all alongside the compiled code (so for every `foo.js` that is generated, we generate `foo.d.ts`).

By default that's not enough, as when you `import puppeteer from 'puppeteer'` in Node land you import `cjs-entry.js`, so we also create `cjs-entry.d.ts` which TypeScript will then pick up. This type file tells TypeScript that the thing that `cjs-entry.js` exposes is an instance of the `Puppeteer` class, which then hooks all the types up.

The previous PR (https://github.com/puppeteer/puppeteer/pull/6289) tried to merge all our typedefs into one big file via API Extractor, but this isn't really necessary a good experience for the developer.

One important consideration is that you _could_ consider this a breaking change. I'm not sure how likely it is, but it could cause problems for:

* Projects that didn't have any type info for Puppeteer and treated all its exports as `any` may now start having legitimate type failures.
* Projects that depend on the `@types/puppeteer` package may have issues if they now swap to use this one and the types aren't quite aligned.

In addition, once we do ship a release with this change in, it will mean that we have to treat any changes to any type definitions as release-note-worthy, and any breaking changes to type definitions will need to be treated as breaking code changes (nearly always a breaking type def means a breaking change anyway), but it's worth considering that once we expose these typedefs we should treat them as first class citizens of the project just like we would with the actual source code.

I also fully expect to have some bugs with our types, or have users create issues/PRs to change our types, but I think that's a good thing and it should settle down.

I've tested this locally by creating a new package, linking Puppeteer via `npm link puppeteer` and then checking that VSCode correctly shows me the right things when I use `Go to Definition` on something that comes from the Puppeteer source code.
2021-01-13 10:37:35 +01:00
Peter Marshall
46e74ff3f5
test: use sourcemaps in unit tests (#6485)
Introduce the source-map-support package and require it for mocha running unit tests.

Turn on the sourceMap option for tsconfig.base.json so that the sourceMappingURL= line is emitted in the generated files.

Co-authored-by: Mathias Bynens <mathias@qiwi.be>
2020-11-26 14:51:17 +01:00
Jack Franklin
caa9a1cafa
chore(agnostic): Remove use of util.promisify (#6446)
In `src/common` we now use `fs.promises.X` which we can dynamically
`import`. In a browser environment this code will never run because it's
gated on `isNode` (in a future PR we will add tree-shaking to the bundle
step such that this code is eliminated). By using `import`, we ensure
TypeScript still can track types and give good type information.

In `src/node` we continue to use `util.promisify` but that's not a
concern as that code explicitly is never run in the browser.
2020-09-28 10:35:35 +01:00
Jack Franklin
f1a6b8d66d
chore: vendor Mitt & update project structure (#6209)
* chore: vendor Mitt into src/common/third-party

As discussed in #6203 we need to vendor our common dependencies in so
that when we ship an ESM build all imports point to file paths and do
not rely on Node resolution (e.g. a browser does not understand `import
mitt from 'mitt'`).
2020-07-14 16:57:29 +01:00