You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Since node is going into the direction of (partial) TypeScript support it might be beneficial for Jest to support that flow automatically together with #9430.
The support can be done on a best-effort basis.
Motivation
Less configuration required
Less dependencies in use - no need to run through Babel
Faster execution 1
Quicker way from bootstrap to running suites
However, even with node 22 and 23 where type stripping (or transformation) can be enabled, this will fail inside jest-runtime where the vm.SourceTextModule expects plain JS and fails inevitably on first : type it finds.
{"name": "native-esm-typescript","version": "1.0.0","jest": {"transform": {"\\.[jt]sx?$": "<rootDir>/jest.typestripping.mjs",// if no transforms are necessary"\\.[jt]sx?$": "<rootDir>/jest.typetransforming.mjs",// if using enums or other unsupported syntax},"extensionsToTreatAsEsm": [".ts"],"testEnvironment": "node"}}
Using this with my integration tests works wonders. It replaces ts-jest and speeds the execution time from ~30s to ~7-8s.
The output string can also be equipped with a source map (for transform cases) and source URL to annotate in the source map.
Pitch
The feature can be hooked into jest-runtime and run automatically depending on available APIs. The runtime already does various checks against node:module, e.g. for createRequire.
Running ESM (which requires disabling transforms) with TypeScript could therefore be as effortless as possible for those wanting to join and use as less build steps as possible.
Footnotes
depending on which transpiler is used and in which mode ↩
The text was updated successfully, but these errors were encountered:
🚀 Feature Proposal
Since node is going into the direction of (partial) TypeScript support it might be beneficial for Jest to support that flow automatically together with #9430.
The support can be done on a best-effort basis.
Motivation
Less configuration required
Less dependencies in use - no need to run through Babel
Faster execution 1
Quicker way from bootstrap to running suites
Example
Consider the native-esm-typescript E2E test.
Should the config be changed to:
However, even with node 22 and 23 where type stripping (or transformation) can be enabled, this will fail inside
jest-runtime
where the vm.SourceTextModule expects plain JS and fails inevitably on first: type
it finds.Node v22.13.0 and v23.2.0 have a module helper stripTypeScriptTypes.
It is possible to write a small shim transformer - my PoC:
jest.typestripping.mjs
jest.typetransforming.mjs
And configure jest to run it:
Using this with my integration tests works wonders. It replaces
ts-jest
and speeds the execution time from ~30s to ~7-8s.The output string can also be equipped with a source map (for transform cases) and source URL to annotate in the source map.
Pitch
The feature can be hooked into
jest-runtime
and run automatically depending on available APIs. The runtime already does various checks againstnode:module
, e.g. for createRequire.Running ESM (which requires disabling
transforms
) with TypeScript could therefore be as effortless as possible for those wanting to join and use as less build steps as possible.Footnotes
depending on which transpiler is used and in which mode ↩
The text was updated successfully, but these errors were encountered: