[Bug]: Linux/WSL: ts-jest Fails with ReferenceError: exports is not defined in setupFiles on First Run (Clean Cache), Fixes Itself After Cache Update

[yegorpetrov]

Version

29.3.1

Steps to reproduce

Minimal repro (incl readme with more details): https://github.com/yegorpetrov/ts-jest-issue-repro/tree/no-eslint

0. Use macOS, ubuntu-latest of GitHub or WSL/Ubuntu. May be some other Linux env (did not check) but not Windows.
1. npm i.
2. Check node node_modules/jest/bin/jest.js --showConfig to see where the cacheDirectory is (e.g. /tmp/jest_rs).
3. Empty the cache directory.
4. Observe the error: npm run test yields ReferenceError: exports is not defined in "jest.setup-files.ts".
5. Try npm run test again to see that the error does not go away.
6. Navigate to jest.setup-files.ts and make any edit, e.g. insert a meaningless space character.
7. npm run test again - there is no error anymore
8. Clean the cache directory and do npm run test once more - the error will reappear.

Expected behavior

I expect ts-jest to execute the test without failures and additional manipulations with the cache or the setup file.

Actual behavior

ts-jest reports an ESM error ReferenceError: exports is not defined in a setup file, but only on Linux (WSL or ubuntu-latest in Github runners).

Debug log

ts-jest-win.log
ts-jest-wsl.log

Additional context

No response

Environment

System:
    OS: Linux 5.15 Ubuntu 20.04.6 LTS (Focal Fossa) **WSL**
    CPU: (12) x64 AMD Ryzen 5 4600H with Radeon Graphics
  Binaries:
    Node: 22.14.0 - ~/.nvm/versions/node/v22.14.0/bin/node
    Yarn: 1.22.10 - /usr/bin/yarn
    npm: 10.9.2 - ~/.nvm/versions/node/v22.14.0/bin/npm
  npmPackages:
    jest: ^29.7.0 => 29.7.0

macOS seems to be affected too.

[yegorpetrov]

I've played with it a little under debugger. It looks like in Linux the Typescript compiler is getting compiler options from ts-jest that were meant for another file.

At line 148 in ts-compiler.js you can see that I'm marking the options object with the file name that it's produced for.
And then at line 128850 in typescript.js you can see that in Linux the wrong object is used.
Windows at the top, Linux (WSL) at the bottom.

Checked this on my colleague's macbook, macOS seems affected too.

---

createProgram is called 7 times in Windows and 3 times in Linux

[yegorpetrov]

Funny. It works on Windows thanks to another bug with backslahes.

If I change it like this...

fileName = fileName?.replace(/\\/g, '/');
if (!this._parsedTsConfig.fileNames.includes(fileName) || !isModuleKindTheSame) {
    shouldIncrementProjectVersion = true;
}

... then I see the same misbehavior on Windows.

But the core issue seems to be the decision not to increment the project version, which apparently is one way to ask tsc to reload compiler options (via synchronizeHostDataWorker() > createProgram()).

Perhaps, the project version should be incremented based on one more thing: when the module kind is different between the previous file and the current one. There is already isModuleKindTheSame but it seems to be made only for the current file.

Anyway, if I modify getCompiledOutput and updateMemoryCache further like this...

...then the bug is gone in both operating systems.

Does this look like a reasonable fix? I mean, the version increment, not the backslash replace hack.

[ahnpnl]

Oh I know there was an issue in the past which was related to backward and forward slash. In the codes of ts-jest, there is a function normaliseSlashes appears in some places is to solve that issue.

fileName input from Jest usually respects OS meanwhile parsedTsconfig.fileNames from typescript I think don’t have that

Indeed, bumping project version is the right way to invalidate file cache.

[ahnpnl]

I think we can combine the conditions for isModuleKindTheSame to be something like currentModuleKind === moduleKind || previousModuleKind && previousModuleKind !== currentModuleKind?