Problem Description
I have a question about the jest.config.ts
that I am setting up.
There I use a moduleNameMapper
, so that imports a la import ... from "@base/..."
also work in the tests. For this I use a function of ts-jest
, which returns the corresponding regular expressions from the tsconfig.json.compilerOptions.paths
. tsconfig.json
is a json file which I am importing with typescript’s resolveJsonModule
option. See here for the documentation on moduleNameMapper.
The function from ts-jest
returns one of the following two objects to be used as the moduleNameWrapper
, depending on other parameters passed. How that works is not relevant for the question, as I am also able to just enter the keys and values directly, not using the ts-jest
function.
First Object: { '^@base/(.*)$': './src/$1' }
Second Object: { '^@base/(.*)$': '<rootDir>/src/$1' }
The first does not work (the modules are then not resolved), the second works correctly.
Question
Hence my question: What does .
mean as a path for jest? What is the difference with <rootDir>
? Why do they both not point to the same directory? My jest config is in the root directory of the project, so I would assume that both .
and <rootDir
would point to the root directory (the folder where the jest config is located). Also see the documentation for rootDir.
What I’ve tried so far
I tried putting both objects in as moduleNameWrapper
in the jest.config, but only the one with rootDir
worked. I would have expected ./src/$1
to have worked as well, but it did not.
The rootDir solution is unsatisfying, as producing the object including <rootDir>
requires an additional options parameter, which sets a prefix. This prefix is hard coded, and could e.g. result in problems further in this project or when using this project as a foundation for the next.
This is the call to create the moduleNameMapper object via ts-jest
:
pathsToModuleNameMapper(compilerOptions.paths, {prefix: "<rootDir>/src/"}),
If the second parameter is omitted, then the dot version is produced, which does not work.
Thanks.