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

Fix NODE_PATH resolving for relative paths #3616

Merged
merged 7 commits into from
May 25, 2017
Merged

Conversation

gaearon
Copy link
Contributor

@gaearon gaearon commented May 19, 2017

The downstream issue was reported in facebook/create-react-app#2230 (comment). The reproducing case is in https://github.com/ingro/cra-test-bug.

Babel Jest transform started climbing directories searching for package.json. People who run Jest with NODE_PATH=src and then import App expecting it to resolve to src/App.js started getting this error:

 ● Test suite failed to run

    Cannot find module 'package.json'

      at Function.Module._resolveFilename (module.js:470:15)
      at Function.Module._load (module.js:418:25)
      at Module.require (module.js:498:17)
      at require (internal/module.js:20:19)

This is because the filename argument to getCacheKey is a relative path in this case. However the function expects it to be absolute, and all other cases I logged showed absolute paths being passed. Even the modulePaths option (which is equivalent to NODE_PATH) gets resolved to absolute paths.

So to fix this, I just make NODE_PATH handling consistent with all other cases in the resolver. They are turned to absolute paths as early as possible. To do this, I use the same code that we’ve been using in Create React App itself for many months.

It is failing because babel-jest traverses directories up searching for package.json, but the path is relative.

It is exposing the underlying issue that NODE_PATH can be relative, but the code assumes all paths are absolute by that point.
This fixes the issue because the rest of the code assumes the path is already absolute.
We also resolve symlink if necessary.
"testEnvironment": "node",
"transform": {
"^.+\\.jsx?$": "../../packages/babel-jest"
}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

babel-jest is the default transform, so it's not necessary to include it

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I only added because it didn't reproduce otherwise. I'm not sure why?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because "babel-jest" would use the version from npm, this is fine.

@jest-bot
Copy link
Contributor

jest-bot commented May 19, 2017

Warnings
⚠️ Please ensure that @flow is enabled on: integration_tests/node_path/src/path/file.js

Generated by 🚫 dangerJS

This test started failing, but it was not testing NODE_PATH in the first place.

It just happened to include its output, and it's not empty on Travis.

The test used to have some copy pasta from how we calculate nodePaths, so I just synced that copy pasta.
@thymikee
Copy link
Collaborator

Hm, what bothers me is that integration_tests/__tests__/node_path-test.js breaks packages/jest-cli/src/reporters/__tests__/CoverageWorker-test.js if ran first, like NODE_PATH would leak from runJest 🤔

@gaearon
Copy link
Contributor Author

gaearon commented May 19, 2017

Side note: it would be curious to see if this also fixes #3069 or not.

@gaearon
Copy link
Contributor Author

gaearon commented May 19, 2017

It does seem to fix #3069 too.

@@ -17,6 +17,7 @@ const JEST_PATH = path.resolve(__dirname, '../packages/jest-cli/bin/jest.js');

type RunJestOptions = {
skipPkgJsonCheck?: boolean, // don't complain if can't find package.json
nodePath?: string,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

abc, please move this up.

@cpojer
Copy link
Member

cpojer commented May 22, 2017

This seems reasonable to me, please fix CI :)

They are empty if NODE_PATH is empty, and split() returns [''].
@gaearon
Copy link
Contributor Author

gaearon commented May 22, 2017

Pushed a fix. It wasn't a timing bug, but an environmental difference.

@gaearon
Copy link
Contributor Author

gaearon commented May 22, 2017

Eh, still broken. I don’t understand, there’s not enough stack and I couldn’t repro locally 😞

@cpojer cpojer merged commit 29dd4d4 into jestjs:master May 25, 2017
@cpojer
Copy link
Member

cpojer commented May 25, 2017

This is very much appreciated @gaearon. Thank you!

@gaearon gaearon deleted the node-path-fix branch May 25, 2017 09:41
tushardhole pushed a commit to tushardhole/jest that referenced this pull request Aug 21, 2017
* Add failing integration test for relative NODE_PATH

It is failing because babel-jest traverses directories up searching for package.json, but the path is relative.

It is exposing the underlying issue that NODE_PATH can be relative, but the code assumes all paths are absolute by that point.

* Resolve NODE_PATH to absolute paths

This fixes the issue because the rest of the code assumes the path is already absolute.
We also resolve symlink if necessary.

* Fix unrelated test to match the code

This test started failing, but it was not testing NODE_PATH in the first place.

It just happened to include its output, and it's not empty on Travis.

The test used to have some copy pasta from how we calculate nodePaths, so I just synced that copy pasta.

* Nitty nit

* Exclude empty items from the array

They are empty if NODE_PATH is empty, and split() returns [''].

* fs.realpathSync() can return undefined

* Fix test to match last change
@github-actions
Copy link

This pull request 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.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators May 13, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants