globalSetup, globalTeardown and testEnvironment does not recognize moduleNameMappers config

[abreu-gyant]

🐛 Bug Report

Modules defined in globalSetup, globalTeardown and in testEnvironment are not being recognized by moduleNameMappers (and maybe others like transform). I think this may be a bug, otherwise consider this as a feature request.

This is maybe related to #5164 and #6179

To Reproduce

1. Create a moduleNameMapper entry in jest config file;
2. Create globalSetup, globalTeardown or testEnvironment files;
3. Import the module alias on those files;
4. Run jest;
5. Cannot find module '<module alias>' error should appear.

Expected behavior

globalSetup, globalTeardown or testEnvironment files should import modules defined on moduleNameMappers config.

Link to repl or repo

1. In the file jest.config.js uncomment globalSetup, globalTeardown or testEnvironment config entries;
2. Open new terminal
3. Run npm run test

https://codesandbox.io/s/jest-module-alias-bug-v3wij

envinfo

  System:
    OS: Linux 5.4 Debian GNU/Linux 10 (buster) 10 (buster)
    CPU: (8) x64 Intel(R) Core(TM) i7-7700 CPU @ 3.60GHz
  Binaries:
    Node: 14.16.1 - ~/.nvm/versions/node/v14.16.1/bin/node
    Yarn: 1.22.10 - ~/.nvm/versions/node/v14.16.1/bin/yarn
    npm: 6.14.12 - ~/.nvm/versions/node/v14.16.1/bin/npm
  npmPackages:
    jest: ^27.0.6 => 27.0.6


  System:
    OS: Linux 5.4 Debian GNU/Linux 10 (buster) 10 (buster)
    CPU: (8) x64 Intel(R) Core(TM) i7-7700 CPU @ 3.60GHz
  Binaries:
    Node: 14.16.1 - ~/.nvm/versions/node/v14.16.1/bin/node
    Yarn: 1.22.10 - ~/.nvm/versions/node/v14.16.1/bin/yarn
    npm: 6.14.12 - ~/.nvm/versions/node/v14.16.1/bin/npm
  npmPackages:
    jest: ^27.0.6 => 27.0.6


  System:
    OS: Linux 5.4 Debian GNU/Linux 10 (buster) 10 (buster)
    CPU: (8) x64 Intel(R) Core(TM) i7-7700 CPU @ 3.60GHz
  Binaries:
    Node: 14.16.1 - ~/.nvm/versions/node/v14.16.1/bin/node
    Yarn: 1.22.10 - ~/.nvm/versions/node/v14.16.1/bin/yarn
    npm: 6.14.12 - ~/.nvm/versions/node/v14.16.1/bin/npm
  npmPackages:
    jest: ^27.0.6 => 27.0.6

[Yilong94]

I can share that I am facing the same issue. For my case, I am importing another module which uses aliases in the module defined for testEnvironment. Initially I had thought it was a misconfiguration in my jest config and I tried all sorts of fixes before I chanced upon this thread and realised that it may be because moduleNameMappers is not respected by testEnvironment 😓

[boredland]

oh damn. this just cost me several hours.

[michaelnwani]

Having the same issue.

[Robin-Didier-MD]

Please solve it

[jbdemonte]

Having the same issue, any plan for this point?

[dan-cooke]

This is such a frustrating bug, with testEnvironment you can remove tonnes of boilerplate setup and teardown code from all of your tests.

But unfortunately its not usable in a modern TS application, as pretty much every app will be using either paths or at least a baseDir to allow relative imports.

Therefore the moduleNameMapper is required

So as it currently stands this bug is blocking out this feature for TS jest users

[pkiing]

Any information on whether this is being fixed?

[AlexSapoznikov]

Any information on whether this is being fixed?

[haschu]

Hello fellow developer who spent many a few hours in rage bugfixing before stumbling across this issue, like me. I might have a quick workaround for you:

Install tsconfig-paths and add import 'tsconfig-paths/register'; on top of your globalSetup or globalTeardown files.

[hasezoey]

i also just run into this while trying to change my code work for both CJS and ESM (because ESM requires explicit endings, but those files do not exist when using ts-jest and having to use globalSetup / globalTeardown for some setup)

using jest 28

[segevfiner]

globals don't apply as well. 😢

[chialunwu]

Bumping this. It's really confusing. The one-liner fix suggested in #11644 (comment) works well. This should be the built-in behavior.

[andoshin11]

hello folks.

#11644 (comment)

Adding import 'tsconfig-paths/register'; on top of my globalSetup initially saved my day for a single spec file Jest project. However, as soon as I add the second .spec.ts file on my project, it crushed again.

[segevfiner]

tsconfig-paths can be quite finicky when combined with Jest as it can take priority over Jest's transformers.

[andoshin11]

Just figured out I can add --runInBand option on Jest CLI to fix the problem. It's highly possible that it ain't work well within the parallel context that Jest provides 🤔

[maghorbani]

I had the same problem, this comment solved it.
this one was not useful

[moshenskyDV]

Hello fellow developer who spent many a few hours in rage bugfixing before stumbling across this issue, like me. I might have a quick workaround for you:

Install tsconfig-paths and add import 'tsconfig-paths/register'; on top of your globalSetup or globalTeardown files.

Helpful.
If it still not works for you guys, make sure that this import goes BEFORE any other import in globalSetup file.

[raisinbread]

Working on an older project that isn't Typescript related, and also running into the same issue.

[aguidrevitch]

Still running into the same issue, even with import 'tsconfig-paths/register';

[AdrianDiazCode]

same issue here, typescript is great but all typescript ecosystem is pure insanity

[G0maa]

Hello, same issue here, this one-liner still fixes it.

[SimenB]

globalSetup is not processed by Jest, so we cannot intercept any require/import calls. I guess we could expose some helpers which uses Jest config to give you what you want? 🤔

[Papooch]

If import 'tsconfig-paths/register'; doesn't work for you, chances are that your tsconfig is named differently than the default - for example in a NX monorepo.

The fix is to set the TS_NODE_PROJECT env variable before importing it, for example:

process.env.TS_NODE_PROJECT = 'tsconfig.base.json';
import 'tsconfig-paths/register';