Support `Node16/NodeNext` value for `moduleResolution`

[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)