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

module: accept Windows relative path #22186

Closed

Conversation

joaocgreis
Copy link
Member

Before this change, require('.\\test.js') failed while require('./test.js') succeeded. This changes _resolveLookupPaths so that both ways are accepted on Windows.

Fixes: #21918 (cc @targos)

Checklist
  • make -j4 test (UNIX), or vcbuild test (Windows) passes
  • tests and/or benchmarks are included
  • commit message follows commit guidelines

@joaocgreis joaocgreis added module Issues and PRs related to the module subsystem. windows Issues and PRs related to the Windows platform. labels Aug 8, 2018
if (parentIdPath === '.' && id.indexOf('/') === -1) {
if (parentIdPath === '.' &&
id.indexOf('/') === -1 &&
(!isWindows || id.indexOf('\\') === -1)) {
id = './' + id;
}
Copy link
Member Author

Choose a reason for hiding this comment

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

This change looked necessary, but this piece of code does not seem to be used anywhere in node core nor tested. newReturn seems to be passed as true everywhere. Hence, I'm not sure about this, let me know if I should leave this as it was.

Copy link
Contributor

Choose a reason for hiding this comment

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

newReturn is for backwards compatibility. There were some people using the private, underscored methods directly and were expecting the old return value.

runTest('./lodash');
if (common.isWindows) {
runTest('.\\lodash');
}
Copy link
Member

@Trott Trott Aug 9, 2018

Choose a reason for hiding this comment

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

Should there be an else clause added that asserts that runTest('.\\lodash') on non-Windows throws or whatever it is supposed to do?

@joaocgreis
Copy link
Member Author

@Trott thanks! Updated.

CI: https://ci.nodejs.org/view/All/job/node-test-pull-request/16346/

cc @nodejs/platform-windows. Not sure who to ping for modules (the modules-active-members team description points to esm), trying some previous commiters: @phillipj @silverwind

Copy link
Member

@phillipj phillipj left a comment

Choose a reason for hiding this comment

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

LGTM

@phillipj
Copy link
Member

Food for thought and too big a discussion for the changes done here, but I feel it's kinda awkward we allow POSIX require paths on Windows, but not Windows paths on POSIX. If we did, it would mean better code portability. But again keeping to POSIX paths would provide that portability cross Windows/POSIX already so 🤷‍♂️

@joaocgreis
Copy link
Member Author

cc @nodejs/modules

I plan to land this next week if there are no objections.

@bmeck
Copy link
Member

bmeck commented Aug 16, 2018

@joaocgreis This seems fine for require to diverge but I would note that import at least on the web will be expecting / to always be used; so, using \\ will likely remain fragile if we are to match how the web is doing resolution. I would not like to see this change occur for import, but this PR seems fine.

Copy link
Member

@benjamingr benjamingr left a comment

Choose a reason for hiding this comment

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

This is a huge change and effectively means that code developed on Windows has a lower chance of working on linux/mac which can cause divergence.

Module paths are not file paths.

I'm not sure I object to the change itself but I think there needs to be more discussion before we simply land this.

@benjamingr
Copy link
Member

benjamingr commented Aug 16, 2018

I would not like to see this change occur for import, but this PR seems fine.

@bmeck why would this be fine for require but not for esm?

Also cc @nodejs/platform-windows

@benjamingr
Copy link
Member

I'd be totally fine with fixing #21918 though only for --require and not the general (in path) case since that is expected to be invoked from outside of Node.

@bmeck
Copy link
Member

bmeck commented Aug 16, 2018

@benjamingr mostly because require is expected to work with filepath-like strings in my mental model and does not do input normalization to some standard format. This is just reinforcing the mental model to me. OS divergence was always part of my mental model for require at least, perhaps thats our difference?

@jdalton
Copy link
Member

jdalton commented Aug 16, 2018

This PR is a small bug fix for cjs. I'm not sure I fully understand all the red x's to hold it.

@benjamingr are you objecting to the comment by @phillipj and not the PR?

Much of Node's code already allows forward and back slashes for Windows in paths. This PR fixes one place where it was missed.

@benjamingr
Copy link
Member

benjamingr commented Aug 16, 2018

@jdalton mostly, I did not want this to get merged without a LGTM from @nodejs/platform-windows since it changes the behaviour to diverge between windows and other platforms further.

If it's consistent and aligns with the policy - then sure.

@jdalton
Copy link
Member

jdalton commented Aug 16, 2018

@benjamingr Ah ok. @joaocgreis is on the platform-windows team. \cc @bzoz for additional review.

Note: \cc @mhdawson I'd like to be added to @nodejs/platform-windows since its a neighboring Microsoft team (DevPlat) that's tasked with this and it has cross-over into my team (WebPlat DevX).

@benjamingr benjamingr dismissed their stale review August 16, 2018 16:32

Clearing my review given clarifications.

@Trott
Copy link
Member

Trott commented Aug 16, 2018

@jdalton: I added you to platform-windows

Copy link
Contributor

@refack refack left a comment

Choose a reason for hiding this comment

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

Let's think about this a little bit more

@refack
Copy link
Contributor

refack commented Aug 16, 2018

What does this produce:

console.log(require('.\\test.js') === require('./test.js'))

P.S. I'm tending towards -1

Much of Node's code already allows forward and back slashes for Windows in paths. This PR fixes one place where it was missed.

@jdalton I'm not sure that is a good enough argument to change CJS semantics... This has been there for the lifespan of CJS, right? I'd rather not change it.

Which brings up other windows FS quirks such as case sensitivity.

console.log(require('.\\test.js') === require('.\\Test.js'))

Or is that allowed while

console.log(require('./test.js') === require('./Test.js'))

is not...

@jdalton
Copy link
Member

jdalton commented Aug 17, 2018

@refack
Currently, today (before this PR) this is how require works on Windows:

The example below assumes a path of C:\projects\demo\bar.js

foo.js

console.log("\n" + [
    path.resolve(".\\bar.js"),
    require(path.resolve(".\\bar.js")),
    require("./..\\demo\\bar.js"),
    require("..\\demo\\bar.js"),
    require("./bar.js")
].join("\n"))

bar.js

module.exports = "bar"

Running node .\\foo.js will log:

C:\projects\demo\bar.js
bar
bar
bar
bar

While I can do node .\\foo.js and require("..\\demo\\bar.js") and require("./..\\demo\\bar.js"), if I was to try to do require(".\\bar.js") from within foo.js it would throw a module not found error.

As a Windows user I've hit this issue on more than one occasion and was surprised it wasn't addressed. It motivated me fix in my own module loader (a year or so back). This inconsistency/oversight is one of the many cuts that makes the Node Windows experience less-great than other platforms.

@refack
Copy link
Contributor

refack commented Aug 17, 2018

@jdalton so the bug is just with . prefixed IDs? .. works? ouch 🤕

I'd still like all of us to think about this, and would like more buy-in...
(plus a few more tests, esp. one that verifies that #21918 is fixed)

@refack
Copy link
Contributor

refack commented Aug 17, 2018

BTW: isn't this semver-major?

@ljharb
Copy link
Member

ljharb commented Aug 17, 2018

@jdalton would you be able to perhaps open a PR to https://github.com/browserify/resolve that adds a test case for this new behavior? :-D

@jdalton
Copy link
Member

jdalton commented Aug 17, 2018

@refack

so the bug is just with . prefixed IDs? .. works? ouch 🤕

Yep. Anywhere there is a one-off path separator check it's easy to overlook. One way to handled this is by abstracting the check to a helper method for broader internal use.

(plus a few more tests, esp. one that verifies that #21918 is fixed)

I dig more tests!

BTW: isn't this semver-major?

It can be.

@ljharb

would you be able to perhaps open a PR to https://github.com/browserify/resolve that adds a test case for this new behavior? :-D

Yep!

@benjamingr benjamingr added the semver-major PRs that contain breaking changes and should be released in the next major version. label Aug 17, 2018
@benjamingr
Copy link
Member

Adding the semver-major tag per the discussion.

@joaocgreis
Copy link
Member Author

I agree with semver-major. Before this, require('.\\test.js') could be used to ignore the current directory when looking for test.js.

CI: https://ci.nodejs.org/view/All/job/node-test-pull-request/16687/

Thanks for the reviews so far! Since this is now semver-major, two reviews from @nodejs/tsc are also required.

@Trott
Copy link
Member

Trott commented Aug 24, 2018

I rebased and tried to force push to fix the dreaded jinja LICENSE CRLF thing, but I don't have permissions to push. @joaocgreis: Can you rebase this against master?

@refack
Copy link
Contributor

refack commented Aug 24, 2018

I rebased and tried to force push to fix the dreaded jinja LICENSE CRLF thing, but I don't have permissions to push. @joaocgreis: Can you rebase this against master?

Wait. If this reproduces the CRLF issue, I want to investigate.

@joaocgreis joaocgreis force-pushed the joaocgreis-I88-require-windows branch from 9e10faa to 98ce2d5 Compare August 24, 2018 21:06
@joaocgreis
Copy link
Member Author

@Trott thanks! Rebased, here we go again: https://ci.nodejs.org/view/All/job/node-test-pull-request/16736/

@refack in case you need, the previous head was 9e10faa54ca78dea007b1b1997d92047c6512037, just the same 3 commits here on top of c6a54af. That was before #22340, the failures look as expected to me. Do you see something unexpected there?

@joaocgreis
Copy link
Member Author

CI is green.

@joaocgreis joaocgreis requested a review from a team August 30, 2018 13:39
Copy link
Member

@Trott Trott left a comment

Choose a reason for hiding this comment

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

LGTM if CITGM doesn't find anything alarming.

Before this change, require('.\\test.js') failed while
require('./test.js') succeeded. This changes _resolveLookupPaths so
that both ways are accepted on Windows.

Fixes: nodejs#21918
@joaocgreis
Copy link
Member Author

@joaocgreis
Copy link
Member Author

@Trott CitGM looks quite red, but similar to master. Do you see anything alarming?

@BridgeAR
Copy link
Member

BridgeAR commented Sep 5, 2018

@joaocgreis the failures all seem unrelated to me. These show up in all CITGM runs. There are still a couple of flakes.

@BridgeAR BridgeAR added the author ready PRs that have at least one approval, no pending requests for changes, and a CI started. label Sep 5, 2018
@BridgeAR
Copy link
Member

BridgeAR commented Sep 5, 2018

@joaocgreis
Copy link
Member Author

@joaocgreis
Copy link
Member Author

CI is all green.

Landed in b36c581.

Thanks for all reviews!

@joaocgreis joaocgreis closed this Sep 12, 2018
joaocgreis added a commit that referenced this pull request Sep 12, 2018
Before this change, require('.\\test.js') failed while
require('./test.js') succeeded. This changes _resolveLookupPaths so
that both ways are accepted on Windows.

Fixes: #21918
PR-URL: #22186
Reviewed-By: Phillip Johnsen <johphi@gmail.com>
Reviewed-By: John-David Dalton <john.david.dalton@gmail.com>
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
author ready PRs that have at least one approval, no pending requests for changes, and a CI started. module Issues and PRs related to the module subsystem. semver-major PRs that contain breaking changes and should be released in the next major version. windows Issues and PRs related to the Windows platform.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

node --require fails with Windows path separator