Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cannot handle absolute paths in moduleNameMapper #55

Open
tf opened this issue Nov 28, 2019 · 4 comments
Open

Cannot handle absolute paths in moduleNameMapper #55

tf opened this issue Nov 28, 2019 · 4 comments

Comments

@tf
Copy link

tf commented Nov 28, 2019

I'm distributing a reusable piece of Jest config in a package, which provides a moduleNameMapper object that maps certain strings to paths in that package. I use absolute paths to make the resolution independent of the actual Jest root dir:

module.export = {
 moduleNameMapper: {
    '^something$': path.resolve(__dirname, './path/in/shared/package'),
   ...
  }
}

Jest can handle this, but eslint-import-resolver-jest does not expect the path to be absolute and always prepends jestConfig.importResolverProjectRoot.

function getAbsolutePath(jestConfig: JestConfig, filepath: Path): Path {
const replacedRoot = filepath.replace(
JEST_ROOT_DIR_PREFIX,
jestConfig.rootDir
);
if (path.isAbsolute(jestConfig.rootDir)) {
return replacedRoot;
}
return path.join(jestConfig.importResolverProjectRoot, replacedRoot);
}

I think, instead of checking whether jestConfig.rootDir is absolute, this case could be covered by checking if replacedRoot instead. Would you accept a PR along these lines?

Workaround

Currently, you can set rootDir to an absolute path in the Jest config which uses the reusable snippet to make it work:

 rootDir: require('path').resolve(__dirname),
@balusio
Copy link

balusio commented May 26, 2020

@tf i faced the same proble with the moduleNameMapper, fortunately, the workarround :
rootDir: require('path').resolve(__dirname) worked!

@chmanie
Copy link
Member

chmanie commented May 26, 2020

Really sorry, I must have missed this. I'd happily accept a PR to fix this properly. The way you suggested @tf sounds good!

@chmanie
Copy link
Member

chmanie commented May 27, 2020

I wonder whether this is also related to #31 🤔

@balusio
Copy link

balusio commented May 27, 2020

@chmanie seems like, let me fork and check if i can help you with this one on a PR

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants