I change the path configuration in my tsconfig, for better paths. But now i cannot execute my testcases. So i checked the following documentaries:
Is that an error or a misconfiguration? By Error i will do a small repo.
Snippet tsconfig.json
...
"rootDirs": [
"src/",
"test/"
],
"baseUrl": ".",
"paths": {
"log": ["src/util/log"],
"server": ["src/server"],
"util/*": ["src/util/*"],
"api/*": ["src/api/*"],
"middleware/*": ["src/middleware/*"],
"service/*": ["src/service/*"],
"types/*": ["src/types/*"],
"test/*": ["test/*"],
"mocks/*": ["test/mocks/*"],
"src/*": ["src/*"]
},
Snippet package.json
...
"globals": {
"ts-jest": {
"tsConfigFile": "tsconfig.json"
}
...
"moduleDirectories": [
".",
"node_modules"
],
"moduleNameMapper": {
"log": "<rootDir>/src/util/log",
"server": "<rootDir>/src/server",
"util/(.*)": "<rootDir>/src/util/$1",
"api/(.*)": "<rootDir>/src/api/$1",
"middleware/(.*)": "<rootDir>/src/middleware/$1",
"service/(.*)": "<rootDir>/src/service/$1",
"types/(.*)": "<rootDir>/src/types/$1",
"test/(.*)": "<rootDir>/test/$1",
"mocks/(.*)": "<rootDir>/test/mocks/$1",
"src/(.*)": "<rootDir>/src/$1"
}
...
ERROR
```bash
● Test suite failed to run
Configuration error:
Could not locate module ../util/params (mapped as C:\Users\XXX\backend\src\util\params)
Please check:
"moduleNameMapper": {
"/util\/(.*)/": "C:\Users\XXX\backend\src\util\$1"
},
"resolver": undefined
```
Can you please create a minimal repo that reproduces this issue?
i hope u can understand the problem and reproduce the issue or the misconfig
Thanks for ur help
Changing the moduleDirectories key in the jest configuration got this working (I tested with jest --no-cache from the root directory)
"moduleDirectories": [
".",
"src",
"src/util",
"node_modules"
]
Hope this helps
This should not have been closed. There is an opportunity to automate this so that developer does not have to touch jest.config.
@DmitryEfimenko if you are using webpack, you'd face the same issue where some path mapped in typescript thanks to the paths config needs its alias in resolve.alias in webpack config.
The option paths is used by the compielr to know that some/path will correspond, at run time, to the file which is NOW at another location. But the typescript compiler is NOT responsible for making those files accessible at runtime. In brief, TS paths setting doesn't affect compiled JS code neither the node resolver.
whatever it does, it seems that all we need to do to make jest work is to put corresponding mappings in the jest.config. I'm not talking about webpack. Just jest and what would it take to make it work.
I understand, and I thought it'd be nice to have, until I had a project where some path mapping in jest were different. For example you'd expect it to not resolve during testing, while you still need to keep the paths for compiling. IF this has to be added, it must be an opt-in.
I'd think it's a rare case when you would not want it.
What if it was behind an option?
{
"jest": {
"globals": {
"ts-jest": {
"autoMapModuleNames": true
}
}
}
}
yup @DmitryEfimenko that is what I meant by being an opt-in.
Example of where you would not want it:
// tsconfig.json:
"paths": {
"app": ["./src/app"],
"common/*": ["../src/common/*"],
"quasar": ["./node_modules/quasar-framework/dist/quasar.mat.esm.js"]
}
// jest.config.js:
moduleNameMapper: {
'^app$': '<rootDir>/src/app',
}
And that is not the only project I work on where both don't match ;-)
But yeah, having an option for it is a good idea. It could be a helper so that people can customize it:
// jest.config.js
const { pathsToModuleNameMapper } = require('ts-jest')
const { compilerOptions: { paths: tsconfigPaths } } = require('./tsconfig')
module.exports = {
// ...
moduleNameMapper: {
...pathsToModuleNameMapper(
tsconfigPaths, // picking/omitting could happen here
// options could be given here
),
'someOtherMapping/(.*)': 'path/to/somewhere/else/$1',
}
}
@DmitryEfimenko https://github.com/kulshekhar/ts-jest/issues/697
and last paragraph of https://github.com/kulshekhar/ts-jest/blob/v23.10.0-beta.1/README.md#module-path-mapping
awesome, thanks!
Anyone test this on windows? I can't seem to get this to work for windows.
I have this problem that should be related to this issue. When I call a module "util" that links to src/util folder, it doesn't work.
moduleNameMapper: {
'^util(.*)$': '<rootDir>/src/util$1'
}
And throws:
Configuration error:
Could not locate module util mapped as:
C:\Users\itsme\Desktop\projecX\src\util.
Please check your configuration for these entries:
{
"moduleNameMapper": {
"/^util(.*)$/": "C:\Users\itsme\Desktop\projecX\src\util$1"
},
"resolver": null
}
at createNoMappedModuleFoundError (node_modules/jest-resolve/build/index.js:472:17)
at Object.<anonymous> (node_modules/micromatch/index.js:7:12)
But when I rename the folder and the module to "utils", in plural... It works.
moduleNameMapper: {
'^utils(.*)$': '<rootDir>/src/utils$1'
}
🤷♂️🙄
@mrjdavidfg Observed the same exact phenomenon. Renaming the folder /util to /utils made the paths to resolve correctly. Seems like a bug.
Hi there!
I'm experiencing the warning Mapping only to first target of "*" because it has more than one (2) when I use pathsToModuleNameMapper
Having multiple path mapping for a pattern is supported by typescript (see https://www.typescriptlang.org/docs/handbook/module-resolution.html#path-mapping). Is there a reason we can't do that here?
@apflieger It looks like the issue with moduleNameMappers not accepting arrays of module paths in the same way that typescript config allows for is an issue with Jest itself. I'll try to muster up the courage to jump in lions' den over there and open an issue about it.
See #1072
@huafu and @apflieger :I have modules in node_modules folder and those dependancies are like below and use it like:
import { NxDatepickerComponent } from '@xyz/ngx-ndbx/datefield/xyz-ngx-ndbx-datefield';
import { NX_DATE_FORMATS } from '@xyz/ngx-ndbx/datefield';
Folder structure is node_modules@xyzngx-ndbxdatefield
For this I have moduleNameMapper as having followings for jest configuaration in package.json file:
"moduleNameMapper": {
"@jkl(.)": "
"@shared(.
"^@xyz/(.)$": "
},
With this configuration only the first import is working and not the second one even if it is in the same folder. Anything I'm missing or doing wrong here?
I'm struggling with this as well. I'm using an nrwl/nx workspace, the paths in tsconfig.app allow the app to run fine, I put the module name mappings in jest.config, nothing. I've tried using the jest utils that do the path to module mappings from tsconfig.app prefixed with rootDir, explicitly putting the entries (so not pulling them in from tsconfig.app), and a hundred other things. Nothing works. You run the tests and any module mapped to a path is not found. The one and only solution I have that works is just to remove the paths and start typing '../../../..' everywhere (which would be dozens of imports).
@tcoz I've found the same thing. Tried suggestions from a dozen or so threads/posts/issues, and nothing works, including the pathsToModuleNameMapper suggestion from the ts-jest docs. I remember getting this to work a few months ago, but for the life of me can't figure out why it doesn't now, even in the simplest of example projects. I wonder if there's a regression somewhere...
path mapping works depending on your rootDir, see https://github.com/kulshekhar/ts-jest/blob/master/TROUBLESHOOTING.md
🤦
In my many stabs-in-the-dark, I'd changed that line to '<rootDir>/src'
roots: ['<rootDir>'] fixed it!
I almost gave up on this but finally fixed it.
// tsconfig.json
{
"compilerOptions": {
"baseUrl": ".",
"paths": {
"@environment": ["src/environment"],
"@test-utils/*": ["src/test-utils/*"]
},
}
The key below was that moduleDirectories was not required to get it to work but modulePaths is. Also a piece of advice is to use <rootDir> instead of ./.
// jest.config.js
const { pathsToModuleNameMapper } = require('ts-jest/utils')
const { compilerOptions } = require('./tsconfig')
module.exports = {
roots: ['<rootDir>'],
modulePaths: ['<rootDir>'],
moduleNameMapper: pathsToModuleNameMapper(compilerOptions.paths),
}
Wish this was automated 🙈 🤦
@DarkLite1 Your solution works like a charm, many thanks!
Most helpful comment
I almost gave up on this but finally fixed it.
The key below was that
moduleDirectorieswas not required to get it to work butmodulePathsis. Also a piece of advice is to use<rootDir>instead of./.