ESM mode: let TypeScript emit ESM codes always when using with Babel

[herschel666]

🚀 Feature Proposal

From my point of view this is a regression, but I guess you had good reasons to bind the module type to the supportsStaticESM-option of Jest. That's why I'm proposing it as a feature: allow to have moduleKind be ESNext independent of Jest's supportsStaticESM-option.

Motivation

The custom Jest preset of the Node/React framework my team and I are maintaining relies on the fact, that the transpiled Typescript, ts-jest passes on to Babel, still contains ES Modules. Otherwise the custom Babel plugin that is part of the preset stops working.

So we rather need the useESM-option to override the supportsStaticESM-option. Then ESM can be enabled implicitly by providing the respective environment to Jest. Or explicitly by setting useESM to true. And vice versa, ESM could be disabled while the environment indicates the opposite to Jest — whoever might need this.

What do you think?

[ahnpnl]

what exactly is the problem?

We don't change the way how module resolution works in the scope of TypeScript compiler. The change to support Jest ESM is: supportStaticESM: true and useESM: true, ts-jest will produce ESM codes.
However, there can be the case supportStaticESM: false (this is decided by Jest) and useESM: true which ts-jest will fallback to produce CJS codes, this is the recommendation from Jest team.

TypeScript module resolution has nothing to do with emitted codes. The emitted codes are decided by module value in tsconfig.

Would you be more clear about the term resolution here?

[herschel666]

@ahnpnl Thanks for the fast reply! 🙏

However, there can be the case supportStaticESM: false (this is decided by Jest) and useESM: true which ts-jest will fallback to produce CJS codes, this is the recommendation from Jest team.

That's exactly the issue: Jest decides that supportStaticESM is false and suddenly, by upgrading Jest and ts-jest to version 27, the code our Babel transformer receives is no longer ESM code but CJS code. The tsconfig.json is ignored. And our custom Babel plugin stops working, because it doesn't find the imported function it is support to alter anymore.

Would you be more clear about the term resolution here?

Sorry, that's a mistake. The module resolution is not the issue here, but the module type of the code that ts-jest's TS compilation emits.

[ahnpnl]

By default, if useESM is false, so emitted codes should always be CJS. If that is not the case, it is clearly a bug. If you see that, please report a bug.

When useESM is true, ts-jest will check:

• supportStaticESM: true: ts-jest will use module from tsconfig to emit ESM codes. If module is not available in tsconfig or its value is not ES2015, ES2020 and ESNext, the default value ESNext will be used.
• supportStaticESM: false: ts-jest will use hardcoded module: CommonJS to emit CJS codes.

That is the implementation which cannot be changed because that is the recommended/must-have implementation required by Jest team.

If the current implementation causes wrong emitted codes, please provide us a repo so that we can check and fix.

[herschel666]

ts-jest is working as expected. But I'm struggling to understand why hardcoding module to CommonJS is a must-have for Jest when supportStaticESM is detected to be false.

What I'm asking for is a way to tell Jest that I don't care about the value of supportStaticESM, but that I set useESM to true, because that's what I want/need it to be. What would be the issue in this case, when I'm taking care of transpiling the code to CJS myself via Babel?

[ahnpnl]

ts-jest is working as expected. But I'm struggling to understand why hardcoding module to CommonJS is a must-have for Jest when supportStaticESM is detected to be false.

This looks not right. You shouldn’t need to hardcode it because ts-jest will handle it automatically. For Babel, the module value doesn’t impact how Babel works.

What I'm asking for is a way to tell Jest that I don't care about the value of supportStaticESM, but that I set useESM to true, because that's what I want/need it to be. What would be the issue in this case, when I'm taking care of transpiling the code to CJS myself via Babel?

ts-jest is a Jest transformer. Transformer is a function which accepts inputs (inputs here come from Jest runtime) and produces transpiled codes.

At the moment, when using ts-jest with Babel, ts-jest will invoke babel-jest, see

ts-jest/src/ts-jest-transformer.ts

Line 197 in a4b88ca

result = babelJest.process(result, filePath, { ...transformOptions, instrument: false })

with whatever transform options that ts-jest receives from Jest runtime, then the rest is up to babel-jest to do the job. Transform options here include supportStaticESM.

By default, when running Jest with Node ESM flag, Jest will mark js, mjs to be treated as ESM files via https://jestjs.io/docs/next/configuration#extensionstotreatasesm-arraystring. The Jest runtime will check this option and perform some logic to set value for supportStaticEsm. ts-jest adds additional ts in the ESM presets.

I’m not sure what you ask can be done, I’m not entirely clear yet what you want to achieve. Do you have some pseudo examples?

[herschel666]

This looks not right. You shouldn’t need to hardcode it because ts-jest will handle it automatically.

I know & that's the issue I'm talking about. ts-jest produces CJS code when Jest "tells" it that ESM is not supported natively. But I don't want ts-jest to take that decision from me. I need ts-jest to produce ESM code in its TS compilation — even in environments that do not support ESM natively. I need ts-jest to always produce ESM code, whatever Jest "says"! I have a Babel plugin in my Jest setup that expects to receive ESM code from the ts-jest-internal TS compilation. And Babel also takes care of producing the CJS code for the Jest runner. So there's no need for ts-jest for being smart here.

It does not matter whether Jest thinks the environment is capable of handling ESM code or not — I need ts-jest to produce ESM code in its TS compilation. And that's currently not easily possible, because ts-jest does not respect user configuration in that matter.

[ahnpnl]

I think the best way to do this is: if user uses Babel, ts-jest can just emit ESM always. What do you think?

[herschel666]

I think the best way to do this is: if user uses Babel, ts-jest can just emit ESM always. What do you think?

Yes, that would be really helpful! 👍

[ahnpnl]

27.0.3 should have the behavior you need

[herschel666]

@ahnpnl Works perfectly fine. Thanks!! 🙏