feat: unforce module CommonJS when testing with ESM #2199
feat: unforce module CommonJS when testing with ESM #2199ahnpnl merged 1 commit intokulshekhar:masterfrom ahnpnl:unforce-module-type
CommonJS when testing with ESM #2199Conversation
ahnpnl
added
the
💣 Breaking Changes
ahnpnl
changed the title
CommonJS when resolving tsconfig
Pull Request Test Coverage Report for Build 419102349
💛 - Coveralls |
ahnpnl
changed the title
CommonJS when testing with ESM
When `extensionsToTreatAsEsm` option is not an empty array, `CommonJS` enforcement will be no longer applicable BREAKING CHANGE To run tests with ESM support, one needs to make sure that: - `module` in tsconfig should be either `es2015` or `es2020` or `esnext` - Use `ts-jest` ESM presets or define value for `extensionsToTreatAsEsm` option properly
| this._overriddenCompilerOptions.module = this.jestConfig.extensionsToTreatAsEsm.length | ||
| ? undefined | ||
| : this.compilerModule.ModuleKind.CommonJS |
There was a problem hiding this comment.
I don't think ts-jest should care about this new option. Transformers will be called with supportsStaticESM: true if import statements can be used and supportsDynamicImport: true if import expressions can be used.
Expressions can be used in both ESM and CJS, but statements only work in ESM mode. I don't think you need to look at the stuff Jest uses to figure out what mode to run, you can just look at those flags
There was a problem hiding this comment.
aw thanks for the info. Actually I was looking for a single flag to decide to unforce. With TypeScript compiler, it's not possible to transform codes with only supportsStaticESM: true or supportsDynamicImport: true.
What do you suggest because it is possible that supportsDynamicImport: false and supportsStaticESM: true or vice versa. When will all ESM options be true ?
There was a problem hiding this comment.
hmm seem like I need to configure preset manually to enable all ESM options. I thought extensionsToTreatAsEsm can automatically enable all ESM options
There was a problem hiding this comment.
There is no single option to force either mode, as most likely CJS will always be a part of the test run (from node_modules). So it's always per file transformed. That said, it will be all .ts files for instance. But yeah, you should probably have separate compilers for CJS vs non-CJS in memory or something so you can switch between them
There was a problem hiding this comment.
I see, so you suggest that CJS should be compiled separately from non-CJS. Any extensions in extensionsToTreatAsEsm should be compiled with non-CJS path.
There was a problem hiding this comment.
yeah, sorta. I don't think you should look at extensionsToTreatAsEsm at all - you should look at the options that is passed to process
There was a problem hiding this comment.
Will ESM options be decided only via jest config or they can be also changed by runtime ?
There was a problem hiding this comment.
runtime, as we lookup package.json to check for type field on .js files https://nodejs.org/api/esm.html#esm_enabling
4 participants
Summary
When
extensionsToTreatAsEsmoption is not an empty array,CommonJSenforcement will be no longer applicable.Test plan
Adjusted unit tests and e2e tests, green CI
Does this PR introduce a breaking change?
To run tests with ESM support, one needs to make sure that:
modulein tsconfig should be eitheres2015ores2020oresnextts-jestESM presets or define value forextensionsToTreatAsEsmoption properlyOther information
N.A