fix: allow modern moduleResolution in project's tsconfig

[akwodkiewicz]

This small change fixes an issue that makes using Jest impossible inside a TypeScript project configured with NodeNext, Node16 or Bundler moduleResolution setting if a Jest configuration file is written in TS.

The default behaviour of ts-node is to read the default tsconfig.json file from the project.
With a hardcoded option of "module: CommonJs" that is used to read the jest.config.ts file, the TypeScript compiler will throw an error, because the modern moduleResolution options are not compatible with
the hardcoded "CommonJs" module value.

The only way to use Jest in such a repo is to change the jest.config.ts file into a JS one (or pass the options in a different way), so that the code responsible of instantiating ts-node is not invoked.

This commit fixes the issue by providing a missing complementary option, moduleResolution: Node, which will work perfectly with module: CommonJs and will not be overridden by any project-specific value in tsconfig.json.

Closes #14740
Closes #13350

[netlify]

✅ Deploy Preview for jestjs ready!

Built without sensitive environment variables

Name	Link
🔨 Latest commit	2a7a0cf
🔍 Latest deploy log	https://app.netlify.com/sites/jestjs/deploys/663353fb340756000845ed85
😎 Deploy Preview	https://deploy-preview-14739--jestjs.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[SimenB]

Thanks! Could you add a test as well? An integration test is probably the thing here

[akwodkiewicz]

Sure thing, I've never done it before in this project, but I'll try to deliver it in the upcoming days.

[akwodkiewicz]

I have a hard time writing those integration tests. I spent two days already, without any success.

First I tried to create a e2e scenario, but it turned out that the config was not even read when the test invoked the runJest testing util, so I got false positives when running tests before the fix.

Then I realized we most likely have to place the test inside jest-config's test suites, but my test ends with the following error:

Error: Jest: Failed to parse the TypeScript config file __fixtures__/readConfigFileTsNodeCompatibility/bundler/jest.config.ts
  Error: You need to run with a version of node that supports ES Modules in the VM API. See https://jestjs.io/docs/ecmascript-modules
    at readConfigFileAndSetRootDir (/Users/andrzejwodkiewicz/Repos/jest/packages/jest-config/src/readConfigFileAndSetRootDir.ts:43:13)
    at processTicksAndRejections (node:internal/process/task_queues:95:5)

Node.js v18.18.2
 FAIL  packages/jest-config/src/__tests__/readConfigFileTsNodeCompatibility.test.ts
  ● Test suite failed to run

    Jest worker encountered 4 child process exceptions, exceeding retry limit

      at ChildProcessWorker.initialize (packages/jest-worker/build/index.js:804:21)

The idea was to create the actual folders representing various flavours of projects that trigger the bug and place them inside a new __fixtures__ folder:

pwd
/Users/andrzejwodkiewicz/Repos/jest/packages/jest-config/src/__tests__

tree
.
├── Defaults.test.ts
├── __fixtures__
│   └── readConfigFileTsNodeCompatibility
│       ├── bundler                             // <- case 1
│       │   ├── jest.config.ts
│       │   ├── package.json
│       │   ├── src
│       │   │   └── test.spec.ts
│       │   └── tsconfig.json
│       ├── node-16                             // <- case 2
│       │   ├── jest.config.ts
│       │   ├── package.json
│       │   ├── src
│       │   │   └── test.spec.ts
│       │   └── tsconfig.json
│       └── node-next                           // <- case 3
│           ├── jest.config.ts
│           ├── package.json
│           ├── src
│           │   └── test.spec.ts
│           └── tsconfig.json
├── __snapshots__
│   └── normalize.test.ts.snap
├── getMaxWorkers.test.ts
├── jest-preset.json
├── normalize.test.ts
├── parseShardPair.test.ts
├── readConfig.test.ts
├── readConfigFileAndSetRootDir.test.ts
├── readConfigFileTsNodeCompatibility.test.ts    // <- my test
├── readConfigs.test.ts
├── readInitialOptions.test.ts
├── resolveConfigPath.test.ts
├── setFromArgv.test.ts
├── stringToBytes.test.ts
└── tsconfig.json

9 directories, 27 files

The test itself:

import path = require('node:path');
import readConfigFileAndSetRootDir from '../readConfigFileAndSetRootDir';

const rootDir = path.join('__fixtures__', 'readConfigFileTsNodeCompatibility');
const moduleResolutionOptions = ['bundler', 'node-16', 'node-next'] as const;

describe('jest is correctly started from using a jest.config.ts file for a project using module/moduleResolution set to', () => {
  test.each(moduleResolutionOptions)('%s', async opt => {
    const readConfig = async () =>
      readConfigFileAndSetRootDir(path.join(rootDir, opt, 'jest.config.ts'));
    expect(readConfig).not.toThrow();
  });
});

[akwodkiewicz]

It is the await import('ts-node') line that throws the ESM error

jest/packages/jest-config/src/readConfigFileAndSetRootDir.ts

Line 115 in 3ed62f0

const tsNode = await import(/* webpackIgnore: true */ 'ts-node');

In all the readConfigFileAndSetRootDir tests there is not a single test that imports a jest.config.ts file. There are mocks of requireOrImportModule, but surely I don't want to mock a ts-node import. I'm stuck.

[akwodkiewicz]

@SimenB, it seems that I'd need to run the tests in the ESM mode, but that is not how all the test suites are configured to run.

Can we merge the PR without an appropriate test suite?

[github-actions]

This PR is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 30 days.

[akwodkiewicz]

@SimenB, would it be possible for you to take a look and suggest how to write an integration test here? Alternatively, make the decision to skip the tests here?

This PR has a solution to an issue that will affect more and more people since TS is now more openly suggesting to stay away from the module: commonjs setting and move to those that cause the #14740 issue

[michaelfaith]

Would recommend going with Node10, which is the "new" name for this value.

[akwodkiewicz]

Good idea!

[akwodkiewicz]

Addressed in 2a7a0cf

[michaelfaith]

It is the await import('ts-node') line that throws the ESM error

jest/packages/jest-config/src/readConfigFileAndSetRootDir.ts

Line 115 in 3ed62f0

const tsNode = await import(/* webpackIgnore: true */ 'ts-node');

In all the readConfigFileAndSetRootDir tests there is not a single test that imports a jest.config.ts file. There are mocks of requireOrImportModule, but surely I don't want to mock a ts-node import. I'm stuck.

Could you mock it and use require to get ts-node instead, so the tests can be in commonjs?

[akwodkiewicz]

Could you mock it and use require to get ts-node instead, so the tests can be in commonjs?

If by "it" you mean the function that contains the await import(...) -- registerTsNode() -- then by mocking it I'd mock my changes so I don't think it would make a good test. The tsconfig options are defined 1 line below the await import():

jest/packages/jest-config/src/readConfigFileAndSetRootDir.ts

Lines 112 to 124 in 3ed62f0

	async function registerTsNode(): Promise<Service> {
	try {
	// Register TypeScript compiler instance
	const tsNode = await import(/* webpackIgnore: true */ 'ts-node');
	return tsNode.register({
	compilerOptions: {
	module: 'CommonJS',
	moduleResolution: 'Node',
	},
	moduleTypes: {
	'**': 'cjs',
	},
	});

Unless you had something else in mind. Like, mocking just the await import() so it means require()? Is that possible?