New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Bug]: TS 5.2 error TS5110: Option 'module' must be set to 'Node16' when option 'moduleResolution' is set to 'Node16' #4198
Comments
getting this as well after updating to TS 5.2.2 |
I have the same issue. As a temporary workaround I've set module.exports = {
transform: {
'^.+\\.tsx?$': [
'ts-jest',
{ tsconfig: { moduleResolution: "classic" } },
],
},
}; |
The code overrides ts-jest/src/legacy/compiler/ts-compiler.ts Lines 155 to 170 in 9f1439a
|
I'm running into this as well and it looks like it's been a month since the last comment. Is there a fix coming out anytime soon for this? |
This patch fixed this issue for our use-case of using --- ./node_modules/ts-jest/dist/legacy/compiler/ts-compiler.js 2023-11-01 13:05:20.000000000 -0700
+++ ./node_modules/ts-jest/dist/legacy/compiler/ts-compiler.fixed.js 2023-11-01 13:09:38.000000000 -0700
@@ -132,7 +132,7 @@
allowSyntheticDefaultImports = true;
}
else {
- moduleKind = this._ts.ModuleKind.CommonJS;
+ moduleKind = this._compilerOptions.module || this._ts.ModuleKind.CommonJS;
}
this._compilerOptions = __assign(__assign({}, this._compilerOptions), { allowSyntheticDefaultImports: allowSyntheticDefaultImports, esModuleInterop: esModuleInterop, module: moduleKind });
if (this._languageService) {
It seems like |
I am experiencing this as well and @erunion 's patch is fixing this issue for me. |
|
There's a bug in ts-jest that makes jest hang if tsconfig.json has a certain combination of module and moduleResolution values. Fix this by providing a differend tsconfig for ts-node. See kulshekhar/ts-jest#4198 and kulshekhar/ts-jest#4207.
There's a bug in ts-jest that makes jest hang if tsconfig.json has a certain combination of module and moduleResolution values. Fix this by providing a differend tsconfig for ts-node. See kulshekhar/ts-jest#4198 and kulshekhar/ts-jest#4207.
I only encounter the issue if I do:
If I leave out the |
In addition to setting |
Does anyone have a workaround for when your jest config file and global setup files are in TS? It does work if my production tsconfig file sets "noEmitOnError" to false, but I don't really want to do that for production code. But with the ts-jest code seeming to invoke ts-node (from what I read) and using my default tsconfig, some of the above workarounds don't seem to work such as the transform or a custom tsconfig file. Also, is this project dead? There hasn't been a release for over 6 months. I'm trying to figure out if we need to start looking at other projects if this project is indeed no longer being maintained. |
There is currently a bug in ts-node where it completely ignores the `module` and `moduleResolution` options kulshekhar/ts-jest#4198
* feat: migrate to ESM * build: fixup `generate-types` script * build: update `ts-node` config to use ESM * build: disable `verbatimModuleSyntax` for `ts-node` There is currently a bug in ts-node where it completely ignores the `module` and `moduleResolution` options kulshekhar/ts-jest#4198 * test: use ESM export for jest
I came here because I wanted to speed up my I solved by it putting the following into my
I don't fully understand the practical difference between Running a trivial test went from 5 seconds to 1 ms. |
Why does ts-jest change If I have to guess I would say it is to change away from Is it possible to fix ts-jest so it keeps the given For people asking what the difference is between // source code: in a .ts file.
const x = import('./module.mjs'); generates this under // TypeScript uses `require` but wraps in a Promise. This would fail at runtime.
const x = Promise.resolve().then(() => require('./module.mjs')); but generates this under // TypeScript uses `import` and this code is correct.
const x = import('./module.mjs'); NodeJS differentiates between the two from the extension |
Simply not explicitly specifying What a mess. Layer upon layer of re-interpreting configs and patching together 20 years of legacy lunacy. What a time to be alive! |
In summary, @erunion workround is for non ESM (without Inferring When setting if ((this.configSet.babelJestTransformer || (!this.configSet.babelJestTransformer && options.supportsStaticESM)) &&
this.configSet.useESM) {
moduleKind =
!moduleKind ||
(moduleKind &&
![this._ts.ModuleKind.ES2015, this._ts.ModuleKind.ES2020, this._ts.ModuleKind.ESNext].includes(moduleKind))
? this._ts.ModuleKind.ESNext
: moduleKind;
// Make sure `esModuleInterop` and `allowSyntheticDefaultImports` true to support import CJS into ESM
esModuleInterop = true;
allowSyntheticDefaultImports = true;
} Meaning there is no way to use If you patch that and allow the |
https://swc.rs/docs/usage/jest has been a good drop-in replacement for us. |
Version
29.1.1
Steps to reproduce
I have a monorepo setup with multiple apps and libraries. One of the apps (the largest, the only one with
isolatedModules: true
) fails after updating to TS 5.2 with the following error:error TS5110: Option 'module' must be set to 'Node16' when option 'moduleResolution' is set to 'Node16'
.Currently using
@tsconfig/node18/tsconfig.json
for the monorepo base config, which contains the following:The
module
option is overridden byts-jest
:100
instead ofnode16
:dist/legacy/config/config-set.js
in_resolveTsConfig()
100
to1
:dist/legacy/compiler/ts-compiler.js
ingetCompiledOutput()
Expected behavior
I would expect that
module
is not changed.Actual behavior
module
is changed first to100
and later to1
(CommonJs)Debug log
extracted info above
Additional context
No response
Environment
The text was updated successfully, but these errors were encountered: