[Bug]: TS 5.2 error TS5110: Option 'module' must be set to 'Node16' when option 'moduleResolution' is set to 'Node16'

[alumni]

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:

{
    "module": "node16",
    "moduleResolution": "node16"
}

The module option is overridden by ts-jest:

• returned 100 instead of node16: dist/legacy/config/config-set.js in _resolveTsConfig()
• from 100 to 1: dist/legacy/compiler/ts-compiler.js in getCompiledOutput()

Expected behavior

I would expect that module is not changed.

Actual behavior

module is changed first to 100 and later to 1 (CommonJs)

Debug log

extracted info above

Additional context

No response

Environment

System:
    OS: Windows 10 10.0.19044
    CPU: (8) x64 Intel(R) Core(TM) i7-8665U CPU @ 1.90GHz
  Binaries:
    Node: 18.17.0 - ~\AppData\Local\fnm_multishells\16532_1692954691139\node.EXE
    Yarn: 1.22.19 - ~\AppData\Local\fnm_multishells\16532_1692954691139\yarn.CMD
    npm: 9.8.1 - ~\AppData\Local\fnm_multishells\16532_1692954691139\npm.CMD
    pnpm: 8.6.12 - ~\AppData\Local\fnm_multishells\16532_1692954691139\pnpm.CMD
  npmPackages:
    jest: ^29.6.4 => 29.6.4

[zapteryx]

getting this as well after updating to TS 5.2.2

[andrew-pledge-io]

I have the same issue. As a temporary workaround I've set moduleResolution to classic in the ts-jest configuration:

module.exports = {
  transform: {
    '^.+\\.tsx?$': [
      'ts-jest',
      { tsconfig: { moduleResolution: "classic" } },
    ],
  },
};

[chentsulin]

The code overrides module in getCompiledOutput():

ts-jest/src/legacy/compiler/ts-compiler.ts

Lines 155 to 170 in 9f1439a

	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
	} else {
	moduleKind = this._ts.ModuleKind.CommonJS
	}

[DavidRigglemanININ]

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?

[erunion]

This patch fixed this issue for our use-case of using @tsconfig/node16 with module: node16 and moduleResolution: node16:

--- ./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 ModuleKind.CommonJS is pretty hardwired throughout ts-jest though so I don't know if anything is being missed here but this at least lets us run our tests with modern resolutions.

[raczkerry]

I am experiencing this as well and @erunion 's patch is fixing this issue for me.

[darkbasic]

node16 works "fine" (at least with "noEmitOnError": false) for me even without the patch: #4207 (comment)

[patrickshipe]

I only encounter the issue if I do:

  transform: {
    '^.+\\.tsx?$': [
      'ts-jest',
      {
        isolatedModules: true,
      },
    ],
  },

If I leave out the isolatedModules option, it works just fine.

[lpc921]

In addition to setting "noEmitOnError": false, I have to leave moduleResolution unspecified when "module": "Node16" or "module": "NodeNext" is set. If I set moduleResolution to Node16 or NodeNext, ts-jest loads the CommonJS version of some packages. See this issue here: Error TS2351 for new SchemaBuilder when testing with ts-jest

[DavidRigglemanININ]

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.

[tobice]

I came here because I wanted to speed up my ts-jest tests by applying isolatedModules: true, which is when I started receiving this error.

I solved by it putting the following into my tsconfig.js:

        "module": "ESNext",
        "moduleResolution": "Node",

I don't fully understand the practical difference between NodeNext and ESNext but it seems to work fine for my case (I just had to change how I import certain npm packages).

Running a trivial test went from 5 seconds to 1 ms.

[InExtremaRes]

Why does ts-jest change module to CommonJS and why this is only apparent if using isolatedModules: true in the jest config?

If I have to guess I would say it is to change away from ESNext if the config doesn't specify useESM but I could be totally wrong. Also this doesn't say why only if isolatedModuels is set.

Is it possible to fix ts-jest so it keeps the given module option as is if it is one of CommonJS, Node16 or NodeNext, defaulting to CommonJS only in other cases? Would that break something?

For people asking what the difference is between CommonJS and NodeNext (beware I'm not an expert) it has to do with CJS and ESM. Basically, under CommonJS TypeScript asumes everything that uses an import can be called with require(); however ESM modules can't be requireed and have to be imported. Under NodeNext TypeScript tries to understand the difference between a CJS and an ESM module so it generates the right JS code. For example this code:

// source code: in a .ts file.
const x = import('./module.mjs');

generates this under CommonJS:

// 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 NodeNext:

// TypeScript uses `import`  and this code is correct.
const x = import('./module.mjs');

NodeJS differentiates between the two from the extension .mjs and TypeScript under NodeNext makes the same distinction (plus some other things like understanding the field "type" in package.json).

[lazarljubenovic]

Simply not explicitly specifying moduleResolution solved the issue for me, leaving only "module": "NodeNext". tsc at least guarantees the same behavior with this config: https://www.typescriptlang.org/docs/handbook/modules/reference.html#implied-and-enforced-options

What a mess. Layer upon layer of re-interpreting configs and patching together 20 years of legacy lunacy. What a time to be alive!

[unional]

In summary, ts-jest doesn't really work with TypeScript 5.2 or above.

@erunion workround is for non ESM (without NODE_OPTIONS=--experimental-vm-modules or useESM is false):
#4198 (comment)

Inferring moduleResolution is the same:
repobuddy/repobuddy#150

When setting NODE_OPTIONS=--experimental-vm-modules and useESM is true,
It will meet this condition and moduleKind is set to ESNext:

        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 moduleResolution: Node16|NodeNext.

If you patch that and allow the moduleKind to stay at Node16|NodeNext, then you will get ReferenceError: exports is not defined errors.

[rthreei]

https://swc.rs/docs/usage/jest has been a good drop-in replacement for us.