Support for esbuild or swc

[isaacl]

🚀 Feature Proposal

Hi, I started with ts-jest on my project, but found startup performance to be unacceptable. I think this is because ts-jest compiles my entire project in order to run tests. There are compilers with significantly better performance, namely esbuild and swc.

swc-node/jest is decent but doesn't cache dependency tree, which means large repos have TONS of duplication compilation.

So maybe an opportunity here? I'm not saying it will be easy!

[ahnpnl]

Definitely those 2 have lots of possibilities to solve the performance problem. They are currently the new trend as well.

We have thought about that. Probably something like an experimental mode to turn on/off which allows using those 2.

[dlqqq]

Any updates 6 months later? Our product team recently switched to esbuild and vite, and we have significantly improved DX here.

I would love to see the same improvement for ts-jest so we don't need to wait a full minute testing each component in a pre-commit hook. ts-jest really is the last commonly-used but slow component in our frontend tech stack. 👍

[simon04]

You might want to give esbuild-jest a try: https://github.com/aelbore/esbuild-jest (caveat: it depends on babel-jest)

[dlqqq]

@simon04 Will definitely do so! I'd love to contribute as well. 👍

[jgonera]

I recently stumbled upon https://github.com/alangpierce/sucrase. Perhaps easier to integrate with since it's written in TypeScript?

[floydjones1]

BUT THERE IS Still one critical problem, I seem to lose type checking when I add transform for either esbuild-jest or @swc/jest. If anyone knows how to fix this issue please let me know! Below is my configuration.
What happens is that this will throw a type error in my test but if I uncomment any one of the transforms I lose that valuable piece

module.exports = {
  preset: "ts-jest",
  verbose: true,
  setupFilesAfterEnv: ["@testing-library/jest-dom/extend-expect"],
  // transform: { "\\.[jt]sx?$": "esbuild-jest" },
  // transform: { "^.+\\.(t|j)sx?$": "@swc/jest" },
  moduleNameMapper: {
    "\\.(css|less|scss|sss|styl)$": "<rootDir>/node_modules/identity-obj-proxy",
  },
};

[floydjones1]

Okay if I change the regex to only look for js and jsx then it catches type errors. But I'm not sure if there is any performance benefit if any.

[sebastianrothe]

Okay if I change the regex to only look for js and jsx then it catches type errors. But I'm not sure if there is any performance benefit if any.

You could check, if you run your tests before and after the change with time

[floydjones1]

Okay if I change the regex to only look for js and jsx then it catches type errors. But I'm not sure if there is any performance benefit if any.

You could check, if you run your tests before and after the change with time

Unfortunately I don't have enough test that I could use to verify with. I think at this point I rather let tsc typecheck only test files and then let esbuild/swc run the transpiling

[sebastianrothe]

BUT THERE IS Still one critical problem, I seem to lose type checking when I add transform for either esbuild-jest or @swc/jest. If anyone knows how to fix this issue please let me know! Below is my configuration.
What happens is that this will throw a type error in my test but if I uncomment any one of the transforms I lose that valuable piece

module.exports = {
  preset: "ts-jest",
  verbose: true,
  setupFilesAfterEnv: ["@testing-library/jest-dom/extend-expect"],
  // transform: { "\\.[jt]sx?$": "esbuild-jest" },
  // transform: { "^.+\\.(t|j)sx?$": "@swc/jest" },
  moduleNameMapper: {
    "\\.(css|less|scss|sss|styl)$": "<rootDir>/node_modules/identity-obj-proxy",
  },
};

That is correct. Esbuild will just throw away your types.

[floydjones1]

I think the best solution would be to use tsc to type-check only test files and then lets esbuild/swc transpile and run test. Seems like there is no way to let the ts-jest type-check when a transform is specified

[lydell]

My dream setup would be this:

1. The tests start running immediately, using esbuild or swc for super fast TypeScript -> JS compilation.
2. tsc is run in parallel.
3. The results of both of those are shown in a clever way.

When I run the tests, I usually have no type errors, because I see them and fix them in my editor. Then I don’t want to wait for tsc. But sometimes I have missed something in my editor. Then I would rather see the type errors from tsc, rather than cryptic test failures like “Expected 5, got undefined”.

[JorisAerts]

I don't know what happened between 27.0.7 and 27.1.0, but now the build on our jenkins server is failing:
➤ YN0056: │ esbuild-linux-64@npm:0.14.2: Cache entry required but missing for esbuild-linux-64@npm:0.14.2

We check in the yarn dependencies and adding this esbuild is now causing issues.

[ahnpnl]

See #3129

[JorisAerts]

See #3129

exactly that

[belgattitude]

Thanks, #3129 solved the peerDependency problem.

Just a note about the types:

ts-jest/src/types.ts

Line 4 in 0e8f829

import type * as _esbuild from 'esbuild'

That will make typescript fail if skipLibCheck !== true in consuming projects that does not have installed esbuild.

No real solution as esbuild does not exports its types.

Example

In P/R: soluble-io/cache-interop#241

Fixed with

[mattsears18]

My dream setup would be this:

1. The tests start running immediately, using esbuild or swc for super fast TypeScript -> JS compilation.
2. tsc is run in parallel.
3. The results of both of those are shown in a clever way.

When I run the tests, I usually have no type errors, because I see them and fix them in my editor. Then I don’t want to wait for tsc. But sometimes I have missed something in my editor. Then I would rather see the type errors from tsc, rather than cryptic test failures like “Expected 5, got undefined”.

@lydell This approach might give you what you're looking for (see 4. What about types?): https://tsh.io/blog/how-to-speed-up-your-typescript-project/

[vertic4l]

Any plans when ts-jest could use esbuild?

[ahnpnl]

We plan start adopting it for v28

[isaachinman]

@ahnpnl v28 was just released. Is esbuild now supported? The changelog doesn't seem to mention it.

[ahnpnl]

Not there yet, it will be opted in as experimental feature. esbuild doesn't support some TypeScript specific features which we need to be careful with adoption.

[Hideman85]

Esbuild drop all the comments so you cannot make the use of /* istanbul ignore next */ in your code.
And it does not seems to be something wanted to be implemented in esbuild see

[epicfaace]

@ahnpnl Do you know if esbuild experimental support is available yet? I see a few instances of it in the codebase (https://github.com/kulshekhar/ts-jest/search?q=esbuild) but not sure if it's able to be used yet or still in progress.

[algoflows]

Any updates on this? Is it time to start looking at migrating to Vitest?