-
Notifications
You must be signed in to change notification settings - Fork 30k
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
module: fix wrong condition in early return logic for node_module path #6670
Conversation
Aside: Why do we need/have a |
Test seems to fail on windows:
|
My fault, it's another different between regex version and manual parsers. The node_modules in root path like |
d8e826e
to
a880856
Compare
Need another CI, @Fishrock123 @mscdex |
This also fixes #6679 FWIW |
@mscdex Looks like the linter is failing again, does that just mean this need rebasing? |
Looks like the windows tests are still failing: https://ci.nodejs.org/job/node-test-binary-windows/2075/
|
@Fishrock123 If the linter is failing it means there is a lint problem that needs to be fixed. The output doesn't display because it's written to a tap file. The linter job doesn't have a tap display page yet. |
Oh.. @hefangshi please run |
a880856
to
453d066
Compare
@Fishrock123 Done, and I used --amend, so the commit is 453d066767f328dc73d6987cc8d30adcad828b79 . I'm sorry that I didn't have test environment for both linux and windows yesterday, so the code was not properly tested. Now the testcases are all passed in my centos6.3 and win10. |
EDIT: it looks like there's something wrong with CI at the moment |
|
||
// return root node_modules when path is 'D:\\'. | ||
// path.resolve will make sure from.length >=3 in Windows. | ||
if (from[from.length - 1] === '\\' && from[from.length - 2] === ':') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about prepending a from.length >= 2
check here and then changing the string equality checks to .charCodeAt()
-based checks? The length check will help prevent a deopt when accessing a non-existent index and the character comparison changes should improve performance a little bit.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about
if (from.length <= 2 ||
(from.charCodeAt(from.length - 1) === 92 /*\*/ &&
from.charCodeAt(from.length - 2) === 58 /*:*/))
return [from + 'node_modules'];
I'm not sure that if from.length is always >=3 (handled by path.resolve on windows), so the from.length - 1 and from.length - 2 is always exist, will v8 still do deopt on it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually on second thought I think it is probably safe to assume from.length >= 2
on Windows. So just the charCodeAt()
changes should be sufficient.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done, should I squash the commits?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It wouldn't hurt
453d066
to
8e57a4e
Compare
CI: https://ci.nodejs.org/job/node-test-commit/3315/ Looks like have an irrelevant failure in windows. |
@Fishrock123 will this patch land in 6.1.1? I think this bug should be fixed ASAP. |
Sorry, I don't really understand this well enough to review. :( v6.2.0 is probably coming out today but this will likely not be in a release until next week as it has not landed yet. |
@bnoordhuis ... can you take a look at this one. |
@mscdex did you have any more thoughts? |
@thealphanerd I'm not familiar enough with the module resolution logic algorithms themselves (much less the Windows side of things) to really comment in detail, so all I can say is to check that CI is ok with it. |
@mscdex But this regression was introduced by you in this commit hefangshi@ae18bbe That's the reason I ping you at the beginning. |
Sorry @Fishrock123, I believe I added that during the v6.2.0 release to make it easier to cherry-pick. Some commits were dependent on semver-major changes. |
I removed that label, the proper one for what you are describing is |
So, any idea? Are we just ignore such a basic bug here? I didn't mean to push this pr land, but I think at least this bug should be fixed. |
citgm failures are unrelated /cc @nodejs/ctc thoughts? |
I think we should land this. I'm having a hard time understanding it enough to make a clear judgement but the test cases are much more thorough so I don't think that should be an issue. @nodejs/collaborators Gona land this next week unless someone objects. |
@Fishrock123 any progress? |
This looks pretty reasonable to me, especially if the added tests fail without the corresponding fix. @hefangshi since this hasn't landed yet, would you be able to add in one more test case? I think the |
@rmg Done, added a global npm node_modules paths testcases. |
Running CI again: https://ci.nodejs.org/job/node-test-pull-request/3474/ I just ran into this myself. LGTM |
Only failure in CI is a known flaky. |
const paths = []; | ||
var p = 0; | ||
var last = from.length; | ||
for (var i = from.length - 1; i >= 0; --i) { | ||
const code = from.charCodeAt(i); | ||
if (code === 92/*\*/ || code === 47/*/*/) { | ||
// use colon as a split to add driver root node_modules |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These comments seem to only apply to the colon, added in this PR. Anyone stumbling on this in the future might be confused by it. Could you expand the comment please. Also, please start comments with a capital letter, and terminate with a period.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done, feel free to give me some advise about the comments since I don't know English too well.
bef38b8
to
88bbb00
Compare
@hefangshi can you format the commit message to follow https://github.com/nodejs/node/blob/master/CONTRIBUTING.md#step-3-commit? Also, we try to avoid using gendered pronouns (like "his"). The last line in the first commit could be updated to something like:
|
The `p < nmLen` condition will fail when a module's name is end with `node_modules` like `foo_node_modules`. The old logic will miss the `foo_node_modules/node_modules` in node_modules paths. TL;TR, a module named like `foo_node_modules` can't require any module in the node_modules folder.
Manual parsers didn't handle the root path on both platform, so push driver root node_modules when colon is matched in windows to avoid parse dirver name and direct push `/node_modules` into paths in posix.
88bbb00
to
b589023
Compare
@evanlucas Thanks for your advice, the commit message issue was fixed. |
Add a real world global node_modules path test case come from npm's dependency to make test more effective.
b589023
to
ff893e4
Compare
alright running CI one more time and landing provided it is green https://ci.nodejs.org/job/node-test-pull-request/3581/ |
The `p < nmLen` condition will fail when a module's name is end with `node_modules` like `foo_node_modules`. The old logic will miss the `foo_node_modules/node_modules` in node_modules paths. TL;TR, a module named like `foo_node_modules` can't require any module in the node_modules folder. Fixes: #6679 PR-URL: #6670 Reviewed-By: Evan Lucas <evanlucas@me.com>
Landed in 55852e1. Thanks! |
The `p < nmLen` condition will fail when a module's name is end with `node_modules` like `foo_node_modules`. The old logic will miss the `foo_node_modules/node_modules` in node_modules paths. TL;TR, a module named like `foo_node_modules` can't require any module in the node_modules folder. Fixes: #6679 PR-URL: #6670 Reviewed-By: Evan Lucas <evanlucas@me.com>
I've marked this as don't land. Please let me know if I was mistaken and it should be backported /cc @cjihrig |
I'm fine with leaving this out of v4, but ping @evanlucas who is more familiar with this commit. |
Checklist
Affected core subsystem(s)
module
Description of change
the
p < nmLen
condition will fail when a module's name is end withnode_modules
likefoo_node_modules
. The old logic will miss thefoo_node_modules/node_modules
in node_modules paths.TL;TR, a module named like
foo_node_modules
can't require any modulein his node_modules folder.
Here is a demo which compared the new nodeModulePaths with the old one.
Output:
The main reason is the
p < nmLen
condition will ignorefoo_node_modules
and simplythink it should be
/node_modules
, and won't search/Users/hefangshi/test/foo_node_modules/node_modules
for dependency.I already tested in mac and windows, but the testcases were not very full edge tested.
@mscdex please have a look on it.