[Feature]: Allow usage of tsm instead of ts-node?

[karlhorky]

🚀 Feature Proposal

Jest allows for configuration in TypeScript via ts-node:

https://github.com/facebook/jest/blob/7f39f0a589703191a0cd3c6db558920281f7195f/docs/Configuration.md?plain=1#L37

It would be great to also enable support for tsm

Motivation

• tsm is lighter weight and faster than ts-node
• if projects are already using tsm for other tasks, it would be nice to not have to also install ts-node only for Jest

Example

No response

Pitch

Not entirely sure I understand this field, but maybe:

It fits Jest's ideology of being fast and enabling modern techniques

[SimenB]

PR very much welcome!

[jensmeindertsma]

The disadvantage to using tsm is that there is no programmatic way to invoke it. This is a problem because then we need to spawn a child process in which we run node --loader tsm jest.config.ts to import the config file. Then we must pass back the imported config to Jest. This can't be done across process boundaries without sacrificing support for function config files.

What I propose instead:

1. Use @swc/cli in a child process like this: npx swc jest.config.,ts -o /node_modules/jest-config/_jest.config.js where /node_modules/jest-config/_jest.config.js is a temporary file.
2. require("/node_modules/jest-config/_jest.config.js") which gives us the config object.
3. Delete the temporary file. -> Now we have the config object available.

I chose swc because of the stability. I know there is also esbuild which tsm uses, and they are similar in size.

@SimenB would you accept a PR implementing this approach?

[SimenB]

would that work if said file imported another ts file? or will swc bundle?

[jensmeindertsma]

If said file imported another TS file, it wouldn't work. I know esbuild can do bundling, that might be an option. I don't know many cases in which you might import from other files though, but yeah, I'd be happy to use esbuild instead and do bundling. Let me know what you prefer ☺️

[SimenB]

@swc/core has a bundle export: https://www.runpkg.com/?@swc/core@1.2.106/index.js#229

(I don't care if swc or esbuild is chosen, I've never used either and haven't cared to check any of them out)

[jensmeindertsma]

Ah, okay. I'll look into it. Just to confirm, you are open to a PR removing ts-node and implementing support for jest.config.ts files with swc or esbuild?

[SimenB]

I don't think we should remove ts-node (but as it would be a breaking change, but also since I don't think any of the alternatives does any type checking?), but making it configurable in some way (--config-loader=blah or some such?) sounds reasonable

[jensmeindertsma]

What would be breaking about removing ts-node? Depending on it's type-checking features would be one? I can do a CLI option

[SimenB]

For people currently using ts-node it would stop working - it's a peer dependency, not a dependency

[jensmeindertsma]

Ah okay. I will implement esbuild under a flag

[jensmeindertsma]

What about a fallback mechanism where Jest will try to parse the config file with esbuild if ts-node is not installed?

[milesj]

If config loading happens within a CJS context, something like this would work just fine: https://boostlib.dev/docs/module#commonjs-requires

[github-actions[bot]]

This issue is stale because it has been open for 1 year with no activity. Remove stale label or comment or this will be closed in 30 days.

[karlhorky]

Not stale? There is also now another alternative called tsx

[SimenB]

Current thinking: https://github.com/facebook/jest/issues/13143#issuecomment-1249081951

I.e. allowing a user to specify which loader to use.

[LinusU]

Both tsm and tsx support would be provided by https://github.com/facebook/jest/pull/13521 🎉

[github-actions[bot]]

This issue is stale because it has been open for 1 year with no activity. Remove stale label or comment or this will be closed in 30 days.

[karlhorky]

Not stale