chore(ci): refactor ts-node compatibility tests
#12834
Conversation
e2e/esm-config/ts/jest.config.ts
Outdated
| import type {Config} from '@jest/types'; | ||
|
|
||
| const config: Config.InitialOptions = { |
There was a problem hiding this comment.
Here integration with ts-node is checked on different OS and Node versions, but without a need to build types.
There was a problem hiding this comment.
can we add some type annotations just to prove it actually does anything else than running it as JS?
e2e/__tests__/tsIntegration.test.ts
Outdated
| 'jest.config.ts': | ||
| 'import type {Config} from "@jest/types";' + | ||
| 'const config: Config.InitialOptions = {displayName: "ts-esm-object-config", verbose: true};' + | ||
| 'export default config;', | ||
| 'package.json': '{"type": "module"}', |
There was a problem hiding this comment.
The same integration check, but with types build properly. There is one difference – this check now runs only on LTS Node (the old test still checks different versions). Here integration with Jest types is checked. Probably that’s fine, because types will work similar between Node versions.
The other difference – here the types are build and bundled properly. The old test did not bundle types.
|
This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Spilt from #12801
44 changed files 🙈. Better to split, that’s too much for such a small change
Summary
In the mentioned PR I was trying to proof that TS configs work with
ts-node. These compatibility tests needed types to be build, but that takes so long (because of"skipLibCheck": false). That’s too slow for CI.In the other hand, types are build for type tests. Hm.. What if
ts-nodecompatibility would be checked in the same job with type tests? Many tests can be run and there is no performance penalty.Test plan
More compatibility tests added.