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';
|
2021-02-11 10:34:44 +00:00
|
|
|
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.',
|
2021-05-26 13:46:17 +00:00
|
|
|
"bad.ts(20,5): error TS2345: Argument of type '(divElem: number) => any' is not assignable to parameter of type 'EvaluateFn<HTMLAnchorElement>",
|
|
|
|
"bad.ts(20,34): error TS2339: Property 'innerText' does not exist on type 'number'.",
|
|
|
|
"bad.ts(24,45): error TS2344: Type '(x: number) => string' does not satisfy the constraint 'EvaluateFn<HTMLAnchorElement>'.",
|
|
|
|
"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.',
|
2021-03-25 11:40:34 +00:00
|
|
|
"bad.js(15,9): error TS2322: Type 'ElementHandle<HTMLElement> | null' is not assignable to type 'ElementHandle<HTMLElement>'",
|
2021-05-26 13:46:17 +00:00
|
|
|
"bad.js(22,5): error TS2345: Argument of type '(divElem: number) => any' is not assignable to parameter of type 'EvaluateFn<HTMLElement>'.",
|
|
|
|
"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.',
|
2021-03-25 11:40:34 +00:00
|
|
|
"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.',
|
2021-03-25 11:40:34 +00:00
|
|
|
"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.',
|
2021-03-25 11:40:34 +00:00
|
|
|
"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()];
|
|
|
|
|
2021-05-26 13:46:17 +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:
|
|
|
|
=> npm run tsc && npm run generate-d-ts
|
|
|
|
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);
|
|
|
|
}
|
|
|
|
|
2021-02-11 10:34:44 +00:00
|
|
|
// 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);
|
|
|
|
|
|
|
|
function compileAndCatchErrors(projectLocation) {
|
|
|
|
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);
|
2021-02-11 10:34:44 +00:00
|
|
|
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',
|
2021-02-11 10:34:44 +00:00
|
|
|
['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: {
|
2021-02-11 10:34:44 +00:00
|
|
|
...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',
|
|
|
|
}
|
|
|
|
);
|
|
|
|
|
|
|
|
if (status > 0) {
|
|
|
|
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) => line.includes('good.ts') || line.includes('good.js')
|
|
|
|
)
|
|
|
|
) {
|
|
|
|
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) => line.includes('bad.ts') || line.includes('bad.js')
|
|
|
|
);
|
|
|
|
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);
|
|
|
|
});
|