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)

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

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

[camsteffen]

This blocks me from doing:

1. Use moduleResolution: bundler in main tsconfig.json
2. Use moduleResolution: nodenext in tsconfig.test.json
3. Use isoluatedModules: true for ts-jest

[erunion]

Confirmed that the work in v29 resolves this for us on a module and moduleResolution of node16. Thanks @ahnpnl!

[drweizak]

This fix i breaking our packages.
We have some packages in our monorepo that fail with the following setup:

package.json:

"type": "module",

tsconfig.json:

  "compilerOptions": {
    "outDir": "./dist",
    "lib": ["ES2023"],
    "module": "NodeNext",
    "target": "ESNext",
    "skipLibCheck": true,
    "moduleResolution": "NodeNext",
    "incremental": true,
    "declaration": true,
}

tsconfig.test.json:

{
  "extends": "./tsconfig.json",
  "compilerOptions": {
    "types": ["node", "jest"],
    "typeRoots": ["../../node_modules/@types"],
    "moduleResolution": "Node",
    "resolveJsonModule": true
  },
  "include": ["./src/index.spec.ts"],
  "exclude": []
}

jest.config.cjs:

const config = {
  preset: 'ts-jest',
  testEnvironment: 'node',

  extensionsToTreatAsEsm: ['.ts'],

  transform: {
    '^.+\\.(ts)$': [
      'ts-jest',
      {
        useESM: true,
        tsconfig: 'tsconfig.test.json',
        diagnostics: {
          ignoreCodes: ['TS151001'],
        },
      },
    ],
  },

  moduleNameMapper: {
    '^(\\.{1,2}/.*)\\.js$': '$1',
  },

  testMatch: ['**/?(*.)+(spec).[tj]s?(x)'],

  testPathIgnorePatterns: ['/node_modules/', '/dist/'],

  verbose: true,

  reporters: ['<rootDir>/minimalReporter.cjs'],
}

module.exports = config

Can anyone please help me understand what i am doing wrong?

I am having issues importing .json files with "import * as xxx from 'x/x/x.json'"
They are convertes into objects, while they are defined as arrays.

[ahnpnl]

@drweizak would you please create a reproduce problem with example apps https://github.com/kulshekhar/ts-jest/tree/main/examples It would be easier to investigate. Thank you.

[drweizak]

@drweizak would you please create a reproduce problem with example apps https://github.com/kulshekhar/ts-jest/tree/main/examples It would be easier to investigate. Thank you.

Thank you for your time! i found out the problem was related how i was importing my files. All is good now :)

before:
import * as x from 'file.json'

now:
import x from 'file.json'

[ahnpnl]

@drweizak is it related to https://www.typescriptlang.org/tsconfig/#allowSyntheticDefaultImports? We did change a bit the behavior there in ff4b302