puppeteer/scripts/test-ts-definition-files.ts

222 lines
7.4 KiB
TypeScript
Raw Normal View History

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
import { spawnSync } from 'child_process';
import { version } from '../package.json';
import path from 'path';
import fs from 'fs';
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
const PROJECT_FOLDERS_ROOT = 'test-ts-types';
const EXPECTED_ERRORS = new Map<string, string[]>([
[
'ts-esm-import-esm-output',
[
"bad.ts(6,35): error TS2551: Property 'launh' does not exist on type",
"bad.ts(8,29): error TS2551: Property 'devics' does not exist on type",
'bad.ts(12,39): error TS2554: Expected 0 arguments, but got 1.',
2022-05-31 14:34:16 +00:00
"bad.ts(20,5): error TS2345: Argument of type '(divElem: number) => any' is not assignable to parameter of type 'EvaluateFn<HTMLAnchorElement, any, any>'.",
"bad.ts(20,34): error TS2339: Property 'innerText' does not exist on type 'number'.",
2022-05-31 14:34:16 +00:00
"bad.ts(24,45): error TS2344: Type '(x: number) => string' does not satisfy the constraint 'EvaluateFn<HTMLAnchorElement, any, any>'.",
"bad.ts(27,34): error TS2339: Property 'innerText' does not exist on type 'number'.",
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
],
],
[
'ts-esm-import-cjs-output',
[
"bad.ts(6,35): error TS2551: Property 'launh' does not exist on type",
"bad.ts(8,29): error TS2551: Property 'devics' does not exist on type",
'bad.ts(12,39): error TS2554: Expected 0 arguments, but got 1.',
],
],
[
'ts-cjs-import-cjs-output',
[
"bad.ts(5,35): error TS2551: Property 'launh' does not exist on type",
"bad.ts(7,29): error TS2551: Property 'devics' does not exist on type",
'bad.ts(11,39): error TS2554: Expected 0 arguments, but got 1.',
],
],
[
'js-esm-import-cjs-output',
[
"bad.js(5,35): error TS2551: Property 'launh' does not exist on type",
"bad.js(7,29): error TS2551: Property 'devics' does not exist on type",
'bad.js(11,39): error TS2554: Expected 0 arguments, but got 1.',
"bad.js(15,9): error TS2322: Type 'ElementHandle<HTMLElement> | null' is not assignable to type 'ElementHandle<HTMLElement>'",
2022-05-31 14:34:16 +00:00
"bad.js(22,5): error TS2345: Argument of type '(divElem: number) => any' is not assignable to parameter of type 'EvaluateFn<HTMLElement, any, any>'.",
"bad.js(22,26): error TS2339: Property 'innerText' does not exist on type 'number'.",
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
],
],
[
'js-cjs-import-esm-output',
[
"bad.js(5,35): error TS2551: Property 'launh' does not exist on type",
"bad.js(7,29): error TS2551: Property 'devics' does not exist on type",
'bad.js(11,39): error TS2554: Expected 0 arguments, but got 1.',
"bad.js(15,9): error TS2322: Type 'ElementHandle<HTMLElement> | null' is not assignable to type 'ElementHandle<HTMLElement>'",
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
],
],
[
'js-esm-import-esm-output',
[
"bad.js(5,35): error TS2551: Property 'launh' does not exist on type",
"bad.js(7,29): error TS2551: Property 'devics' does not exist on type",
'bad.js(11,39): error TS2554: Expected 0 arguments, but got 1.',
"bad.js(15,9): error TS2322: Type 'ElementHandle<HTMLElement> | null' is not assignable to type 'ElementHandle<HTMLElement>'",
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
],
],
[
'js-cjs-import-cjs-output',
[
"bad.js(5,35): error TS2551: Property 'launh' does not exist on type",
"bad.js(7,29): error TS2551: Property 'devics' does not exist on type",
'bad.js(11,39): error TS2554: Expected 0 arguments, but got 1.',
"bad.js(15,9): error TS2322: Type 'ElementHandle<HTMLElement> | null' is not assignable to type 'ElementHandle<HTMLElement>'",
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
],
],
]);
const PROJECT_FOLDERS = [...EXPECTED_ERRORS.keys()];
2022-05-31 14:34:16 +00:00
if (!process.env['CI']) {
console.log(`IMPORTANT: this script assumes you have compiled Puppeteer
and its types file before running. Make sure you have run:
2022-06-10 09:55:53 +00:00
=> npm run build:tsc && npm run generate:types
before executing this script locally.`);
}
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
function packPuppeteer() {
console.log('Packing Puppeteer');
const result = spawnSync('npm', ['pack'], {
encoding: 'utf-8',
});
if (result.status !== 0) {
console.log('Failed to pack Puppeteer', result.stderr);
process.exit(1);
}
// Move from puppeteer-X.Y.Z.tgz to puppeteer.tgz so we don't have to update
// it when versions change.
const moveResult = spawnSync('mv', [
`puppeteer-${version}.tgz`,
'puppeteer.tgz',
]);
if (moveResult.status !== 0) {
console.log('Failed to rename Puppeteer tar', moveResult.stderr);
process.exit(1);
}
return `puppeteer.tgz`;
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
}
const tar = packPuppeteer();
const tarPath = path.join(process.cwd(), tar);
2022-05-31 14:34:16 +00:00
function compileAndCatchErrors(projectLocation: string) {
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
const { status, stdout, stderr } = spawnSync('npm', ['run', 'compile'], {
cwd: projectLocation,
encoding: 'utf-8',
});
const tsErrorMesssage = stdout.split('\n');
if (status === 0) {
console.error(
`Running tsc on ${projectLocation} succeeded without triggering the expected errors.`
);
console.log(stdout, stderr);
process.exit(1);
}
return {
tsErrorMesssage,
};
}
function testProject(folder: string) {
console.log('\nTesting:', folder);
const projectLocation = path.join(
process.cwd(),
PROJECT_FOLDERS_ROOT,
folder
);
const tarLocation = path.relative(projectLocation, tarPath);
console.log('===> Clearing left over node_modules to ensure clean slate');
try {
fs.rmdirSync(path.join(projectLocation, 'node_modules'), {
recursive: true,
});
} catch (_error) {
// We don't care if this errors because if it did it's most likely because
// there was no node_modules folder, which is fine.
}
console.log('===> Installing Puppeteer from tar file', tarLocation);
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
const { status, stderr, stdout } = spawnSync(
'npm',
['install', tarLocation],
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
{
env: {
...process.env,
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
PUPPETEER_SKIP_DOWNLOAD: '1',
},
cwd: projectLocation,
encoding: 'utf-8',
}
);
2022-05-31 14:34:16 +00:00
if (status) {
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
console.error(
'Installing the tar file unexpectedly failed',
stdout,
stderr
);
process.exit(status);
}
console.log('===> Running compile to ensure expected errors only.');
const result = compileAndCatchErrors(projectLocation);
const expectedErrors = EXPECTED_ERRORS.get(folder) || [];
if (
result.tsErrorMesssage.find((line) => {
return line.includes('good.ts') || line.includes('good.js');
})
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
) {
console.error(
`Error for ${projectLocation} contained unexpected failures in good.ts/good.js:\n${result.tsErrorMesssage.join(
'\n'
)}`
);
process.exit(1);
}
const errorsInTsMessage = result.tsErrorMesssage.filter((line) => {
return line.includes('bad.ts') || line.includes('bad.js');
});
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
const expectedErrorsThatHaveOccurred = new Set<string>();
const unexpectedErrors = errorsInTsMessage.filter((message) => {
const isExpected = expectedErrors.some((expectedError) => {
const isExpected = message.startsWith(expectedError);
if (isExpected) {
expectedErrorsThatHaveOccurred.add(expectedError);
}
return isExpected;
});
return !isExpected;
});
if (unexpectedErrors.length) {
console.error(
`${projectLocation} had unexpected TS errors: ${unexpectedErrors.join(
'\n'
)}`
);
process.exit(1);
}
expectedErrors.forEach((expected) => {
if (!expectedErrorsThatHaveOccurred.has(expected)) {
console.error(
`${projectLocation} expected error that was not thrown: ${expected}`
);
process.exit(1);
}
});
console.log('===> ✅ Type-checked correctly.');
}
PROJECT_FOLDERS.forEach((folder) => {
testProject(folder);
});