globalSetup does not work with moduleNameMappers. In most setups this would be ok, but there are situations such as SSR where you want to setup a server once, you can run into issues with this.
Related to: https://github.com/facebook/jest/issues/5164
globalSetup processes moduleNameMappers. The idea that globalSetup runs before "everything" is not practical. Setup will generally require some configuration options for things to work.
npx envinfo --preset jestPaste the results here:
System:
OS: macOS Sierra 10.12.6
CPU: x64 Intel(R) Core(TM) i7-3615QM CPU @ 2.30GHz
Binaries:
Node: 8.9.4 - ~/.nvm/versions/node/v8.9.4/bin/node
Yarn: 1.5.1 - /usr/local/bin/yarn
npm: 6.0.0 - /Users/Shared/java/projects/react/projects/mobile-minds/node_modules/.bin/npm
npmPackages:
jest: 22.4.3 => 22.4.3
The workaround I currently use for both this issue and the related babel-transpile issue:
require('babel-register');
require('babel-polyfill');
['.css', '.eot', '.woff', '.ttf'].forEach(ext => {
require.extensions[ext] = () => ({});
});
['.svg', '.png', '.jpg'].forEach(ext => {
require.extensions[ext] = () => '';
});
Any updates on this issue?
This seems like a feature request, can you post a full example of the bug?
same
Here is a runnable reproduction of the bug:
https://codesandbox.io/s/boring-wilbur-ibkmj
1 - Un-comment globalSetup line in jest.config.js:
globalSetup: './tests/globalSetup.js'
2 - Run the following in the terminal:
yarn test
Error output:
Error: Cannot find module '@/utils'
at Function.Module._resolveFilename (internal/modules/cjs/loader.js:636:15)
at Function.Module._load (internal/modules/cjs/loader.js:562:25)
at Module.require (internal/modules/cjs/loader.js:690:17)
at require (internal/modules/cjs/helpers.js:25:18)
at Object.<anonymous> (/sandbox/tests/globalSetup.js:3:5)
at Module._compile (internal/modules/cjs/loader.js:776:30)
at Module._compile (/sandbox/node_modules/pirates/lib/index.js:99:24)
at Module._extensions..js (internal/modules/cjs/loader.js:787:10)
at Object.newLoader [as .js] (/sandbox/node_modules/pirates/lib/index.js:104:7)
at Module.load (internal/modules/cjs/loader.js:653:32)
Hi everyone! friendly ping
@rickhanlonii @SimenB
This seems like a feature request, can you post a full example of the bug?
I have to disagree. I don't think this is a feature request but rather a bug:
The moduleNameMapper configuration is correctly respected in all setupFilesAfterEnv and setupFiles for example. globalSetup and globalTeardown surprisingly don't respect that :/
I prepared a simple reproduction on the latest jest version 25.2.7, see https://codesandbox.io/s/jest-globalsetup-modulenamemapper-bug-g1ol7 and the README.
This is currently preventing us from speeding up our test setup substantially, because we cannot re-use a service for all tests and instead have to re-create it for every test file by putting it in a setupFiles entry. We'd love to see this fixed, let me know if I can be of any more help!
Thank you :)
Thanks for the repro cases, I agree this is a bug now (or a feature request to change the behavior, however you want to look at it). If anyone wants to submit a PR to fix it I'm happy to review!
If anyone wants to submit a PR to fix it I'm happy to review!
@rickhanlonii I'm happy to take a look at it. Do you have any recommendations into where I might start looking as a first-time contributor? Thanks!
@stnwk I do not - I would grep for setupFilesAfterEnv and track down how it uses moduleNameMapper, and then grep for globalSetup to see why it doesn't use it. Let me know if you have any questions 馃憤
Most helpful comment
Here is a runnable reproduction of the bug:
https://codesandbox.io/s/boring-wilbur-ibkmj
Reproduction steps
1 - Un-comment
globalSetupline injest.config.js:2 - Run the following in the terminal:
Error output: