It is causing failed builds and we are not currently using it, plus we
want to move this setup into a new repository, such that it can run
independently of Puppeteer's main codebase.
For now, until that work is done, let's remove it to not cause build
issues and to not waste cycles on CI.
It is flakey on the bots and we're not actively using it yet, so let's
disable it for now. We will work on extracting this into its own repo
and that work is tracked in
https://github.com/puppeteer/puppeteer/issues/7710.
We now generate the docs into `website/docs` such that it's used by
Docusaurus when we build the site, we need to update the deploy script
to generate those docs first.
* chore: enforce pinned dependencies
Because we don't check our `package-lock.json` in, we can end up with
different versions installed locally vs CI, or even two devs having
different versions. Let's pin and enforce we pin every version to
avoid this.
* chore: temporarily disable FF tests on CI
The tests are regularly flaking (see #6861 for some investigation). In
the mean time it's blocking us landing and releasing, so we'll
temporarily skip FF tests for now.
Co-authored-by: Mathias Bynens <mathias@qiwi.be>
* 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.
Similar to our earlier Travis CI setup, we continue to run exhaustive checks on Linux, while also verifying the build + unit tests still work on other platforms.
Issue: #6726
