kulshekhar/ts-jest

[Bug]: TS 5.2+ fails if using `nodenext` module resolution and `noEmitOnError` is `true`

mogzol opened this issue · 2 comments

Version

29.1.1

Steps to reproduce

Set up your package as a module, and use any Typescript version greater than or equal to 5.2.2:

// package.json
{
  "type": "module",
  "dependencies": {
    "@types/jest": "^29.5.10",
    "jest": "^29.7.0",
    "ts-jest": "^29.1.1",
    "typescript": "^5.2.2"
  }
}

In your tsconfig.json, use nodenext module resolution, and set noEmitOnError to true:

// tsconfig.json
{
  "compilerOptions": {
    "module": "nodenext",
    "moduleResolution": "nodenext",
    "noEmitOnError": true,
  },
}

Set your jest config to use ts-jest:

// jest.config.js
export default {
  transform: { "^.+\\.tsx?$": ["ts-jest"] },
};

Set up a simple test with ts-jest:

// test.ts
it("should pass", () => expect(1).toBe(1));

Run it:

npx jest

Expected behavior

The test should pass (which it does on TS 5.1.6 and below).

Actual behavior

On TS >= 5.2.2, the test fails with the error:

Unable to process '/path/to/test.ts', please make sure that `outDir` in your tsconfig is neither `''` or `'.'`. You can also configure Jest config option `transformIgnorePatterns` to inform `ts-jest` to transform /path/to/test.ts

      at TsCompiler.getCompiledOutput (node_modules/ts-jest/dist/legacy/compiler/ts-compiler.js:173:27)

Downgrading to TS 5.1.6 allows the test to pass. Or setting noEmitOnError in tsconfig.json to false also allows the test to pass.

Debug log

ts-jest.log

Additional context

No response

Environment

System:
    OS: macOS 14.1.2
    CPU: (16) x64 Intel(R) Core(TM) i9-9980HK CPU @ 2.40GHz
  Binaries:
    Node: 20.9.0 - /usr/local/bin/node
    Yarn: 1.22.19 - /usr/local/bin/yarn
    npm: 10.1.0 - /usr/local/bin/npm
    pnpm: 8.10.2 - /usr/local/bin/pnpm
  npmPackages:
    jest: ^29.7.0 => 29.7.0

Sounds like a duplicate of #4198

Thanks, I do get a different error than that issue, but it does seem to at least be related to #4198 and #4207, and in the comments for #4207 there's people mentioning the same error message I get (and the same solution, disabling noEmitOnError), so I'm going to close this.