Jest does not respect NODE_PATH

[iamrandys]

In our project we do not use any relative paths in require statements. Instead of require('../../../ui/button') from inside a module in the components package, we simply use require('components/ui/button') everywhere. This way if we move the button code around, we can do a simple search and replace in the project to update all of the require statements. To accomplish this we set NODE_PATH="." and we are done (export NODE_PATH="." at the command line or process.env.NODE_PATH='.' in the code). Browserify, Webstorm and node all respect the process.env.NODE_PATH setting. It would be great if Jest's HasteModuleLoader could be updated to check the NODE_PATH for user modules as well. It looks like it is checking to see if it is a IS_PATH_BASED_MODULE_NAME, but it's not so it errors out. It would be nice if it would also check each of the paths in NODE_PATH before giving up.

[Chrazy]

I'm also having an issue with this using webpack and defining paths with the "modulesDirectories" parameter (http://webpack.github.io/docs/configuration.html#resolve-modulesdirectories).

I'd like to see a similar option to be able to declare (multiple) module directories.

[iamrandys]

I updated our project to use a more standard node module setup. As soon as I added a package.json to my packages and started using relative paths within each module, my issue was resolved. So if you have to use a require with ../../../../.., that code should really be split out into another package.

[jeffmo]

Thanks for the issue! Re-opening because the original topic still applies: Jest should probably respect the NODE_PATH env variable in it's resolution algorithm since that's what Node does.

I'm personally strapped on resources at the moment myself, but I'd love to see support for this happen. Hopefully when I can get some time I can dive in to this -- otherwise would be happy to consider a pull request.

[hojberg]

Hit into this issue today - would love to see this addressed soon

[davidmccabe]

Can't use Jest because of this issue.

[martindanielson]

Really need this in order to be able to be a little flexible when it comes to how you organize your projects. NODE_PATH is one thing, but we also have split out common components in another project, referencing this does not resolve either.

This should be easy to do right, and add great flexibility. Please prioritize this.

[limscoder]

+1

Here's a function you can call in your jest preprocessor to rewrite the require statements to use absolute paths to work around this issue.

var replacePath = function(src, path) {
    var rootPath = path.match(/^.*myprojectdirectoryname\//)[0];
    return src.replace(/require\((['"])components/, 'require($1' + rootPath + 'components/', 'g');
};

[volkanunsal]

There are at least 4 issues that pertain to this problem, and there is a PR that fixes this in #133 that was submitted months ago. Why is it taking so long to test and merge it into the master branch?

[gbbr]

I assume this applies to resolve.alias being ignored as well. I'm using WebPack + React which works fine with the aliases but the jest-cli runner (using gulp-jest) seems to completely ignore them both in tests and imported packages.

Example: resolve: { alias: { app: "/path/to/app" } } will correctly load /path/to/app/component.js when doing require "app/component" but not within JEST or from JEST.

This is kinda nasty. Since Facebook has been using this for years now - how do you get around relative paths? Or are you using relative paths? If so, why?

It doesn't seem that difficult to add into the HasteLoader

[hasPatrickC]

👍 just ran into this issue

[akulapid]

+1 to be consistent with what node does.
Hope this is prioritized. Any probable timeline for this fix?

[daviferreira]

👍

[Sushindhran]

👍

[captainsano]

👍

[tchcxp]

Hi guys,

Any update for this issue?

Thanks.

[gbbr]

This is pretty bad. I can't even use aliases in my application if I'm using JEST because the tests will fail - JEST can't resolve the alias. I don't know how you guys can live with this.

This issue has been open for ages and there are already several PRs active that aim to solve it.

[gbbr]

I think nobody's home :)

[volkanunsal]

The person who made the PR that fixes this issue hasn't responded to @jeffmo's feedback. So it's not that nobody is home, but developing open source software with community participation is kind of tricky. If @jeffmo fixes this issue and ignore the pull request, he might catch flak for it, and I think that's why he hasn't taken on this issue.

I think for mission critical stuff like this, you hope the maintainer will take the lead to fix the issue himself. There are too many people waiting for this issue to get fixed. Let's hope someone is listening. :)

[hojberg]

@volkanunsal it is true I dropped the ball on this - A few days ago @carrbs opened a new pull though #246

[carrbs]

Thanks @hojberg,

Yes, #246 covers all this, has testing and is not platform specific. Please
take a look, and let me know if you think it needs anything. I'm motivated
to get this merged ASAP as we're using this code in prod.
On Feb 15, 2015 8:38 AM, "Simon Højberg" notifications@github.com wrote:

@volkanunsal https://github.com/volkanunsal it is true I dropped the
ball on this - A few days ago @carrbs https://github.com/carrbs opened
a new pull though #246 #246

—
Reply to this email directly or view it on GitHub
#102 (comment).

[volkanunsal]

That's great news. Thanks @carrbs and @hojberg.

[gbbr]

Can I push the line and ask whether aliases will work? (#246)

[carrbs]

@gbbr - yes, if you mean in package.json, if you do something like: NODE_PATH=\"$(pwd)/src\

So long as NODE_PATH is set to an absolute path it will work. But maybe I misunderstand your question?

[gbbr]

Oops... that's a webpack feature. My bad. It's a config option called
"resolve.alias" in WebPack where you can use an alias for a path. I wonder
if that'll work after this patch. If it will - that would be awesome :)

On 16 February 2015 at 22:24, Benjamin Sanabria Carr <
notifications@github.com> wrote:

@gbbr https://github.com/gbbr - yes, if you mean in package.json, if
you do something like: NODE_PATH="$(pwd)/src\

So long as NODE_PATH is set to an absolute path it will work. But maybe I
misunderstand your question?

—
Reply to this email directly or view it on GitHub
#102 (comment).

[jeffmo]

Hey everyone, very sorry. I've been missing out on all the latest updates to this thread but this basically just slipped my radar.

I will go commandeer that initial pull request and bring it up to date tomorrow when I get back to the office.

Sorry for dropping the ball here everyone, my bad.

[carrbs]

Hi @jeffmo,
#246 should have all the goods on it, that PR has tests and responds to other people's concerns about different platforms.

[jeffmo]

Thanks @carrbs. Just merged #246 and published jest-cli@0.4.0 with it

[hojberg]

Awesome! thnaks @jeffmo

[carrbs]

woot! thanks @jeffmo

[binarykitchen]

totally agree with @gbbr 's comment, see #269 and #270 ... is there any progress?

[binarykitchen]

I cannot use the preprocessor to rewrite the require statements because it seems that an error of a failed required module is thrown before calling the preprocessor.

[rikukissa]

Found myself getting Cannot find module 'react' from ... error after setting the NODE_PATH variable.
Jest seems to be calling node-resolve like this:

resolve.sync('react', {
  paths: 'resources', 
  basedir: 'resources/components/button', 
  exts: [ '.js', '.json', '.jsx' ]
});

Where 'resources' is the path in my NODE_PATH and 'resources/components/button' where the component requiring React lives. With this call node-resolve searches modules from

resources/components/button/node_modules,
resources/components/node_modules,
resources/node_modules and from resources,
but ignores node_modules completely and for that reason fails to find React.

My temporary solution for this was to use NODE_PATH=resources:node_modules jest which seems to work fine, but I'd definitely want to know am I doing something wrong or is there something wrong with node-resolve. In my opinion Jest seems to be using it correctly. Any ideas?

[alvinsj]

There is another issue I noticed, after NODE_PATH is used and got the happy require working.

Make sure the paths are consistent everywhere, otherwise dontMock/setMock won't work.

e.g.:
jest.dontMock('components/unhappy') // in your test
won't work with
require('./unhappy') //in your code. e.g. components/happy.react.jsx

maybe there is no such feature yet to recognize the same path references?

[RobinClowers]

I'm running into this bug on my CI server, anyone have a workaround?

[cpojer]

Jest definitely respects the NODE_PATH and has for a year at least. You are probably running into some other issue.

[RobinClowers]

Sorry, somehow I thought this issue was still open.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Please note this issue tracker is not a help forum. We recommend using StackOverflow or our discord channel for questions.