You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
require(".\\") doesn't resolve index.js on Windows #18299
While looking at #15015 (comment) I noticed that the trailing slash check in _findPath was only keying off of a forward slash and not the backslash that Windows allows.
You can repro this by simply doing the following in a directory with an index.js
require(".\\")// throwsrequire("./")// will find the index.js
Other places in Node account for the backslash in Windows paths so this looks like an oversight.
Update:
It looks like if it's a two dot relative path to an index.js then it does work.
require("..\\")// workrequire("..\\.")// worksrequire("../")// worksrequire("../.")// works
Also this
require("./..")// worksrequire(".\\..")// throws
Notes:
It looks like path.resolve handles these cases fine so it can be excluded from the problem.
@jdalton I think we could probably have windows normalize \\ to / in all cases [like the URL spec does], is there a case where \\ doesn't act like / in the existing usage of paths on win32?
@jdalton I think we could probably have windows normalize \\ to / in all cases [like the URL spec does], is there a case where \\ doesn't act like / in the existing usage of paths on win32?
I'm curious about the answer to @bmeck's question here, and also if this is still an issue?
There's been no further action on this. Closing, but given that it's not fully resolved, I'm putting this on the Futures project board so that it does not get lost.
An unresolved issue that no one ever looks at isn't useful either. These can always be reopened if someone intends to pick it up. Also, after I'm done taking a triage pass at all these stale old issues I'll be compiling a list of outstanding issues for each subsystem
I've reopened but as I said, "I'm putting this on the Futures project board so that it does not get lost." and "after I'm done taking a triage pass at all these stale old issues I'll be compiling a list of outstanding issues for each subsystem" ...
As this appears to be fixed on all supported versions, I'm going to close it. Of course, if that's wrong and it's still an issue somewhere, please comment or re-open.
Activity
jdalton commentedon Jan 22, 2018
It looks like part of the issue is in
Module._resolveLookupPathsbecause it's only looking for a forward slashnode/lib/module.js
Line 365 in a3555d0
but is snipped:
Module._resolveLookupPathsis fixed though it'll run into issues with #15015.bmeck commentedon Jan 24, 2018
@jdalton I think we could probably have windows normalize
\\to/in all cases [like the URL spec does], is there a case where\\doesn't act like/in the existing usage of paths on win32?Replace all backslashes with forward slashes in paths
Replace all backslashes with forward slashes in paths (#12)
Trott commentedon Jul 20, 2019
I'm curious about the answer to @bmeck's question here, and also if this is still an issue?
Trott commentedon Jul 20, 2019
@jdalton ^^^^
Trott commentedon Apr 22, 2020
@nodejs/modules-active-members @jdalton Should this be closed? Or is this an issue that should be addressed?
jasnell commentedon Jun 25, 2020
There's been no further action on this. Closing, but given that it's not fully resolved, I'm putting this on the Futures project board so that it does not get lost.
ljharb commentedon Jun 25, 2020
@jasnell why would an inactive issue that's still a problem be closed?
jasnell commentedon Jun 25, 2020
An unresolved issue that no one ever looks at isn't useful either. These can always be reopened if someone intends to pick it up. Also, after I'm done taking a triage pass at all these stale old issues I'll be compiling a list of outstanding issues for each subsystem
ljharb commentedon Jun 25, 2020
How can anyone ever decide to pick it up if it's closed?
jasnell commentedon Jun 26, 2020
I've reopened but as I said, "I'm putting this on the Futures project board so that it does not get lost." and "after I'm done taking a triage pass at all these stale old issues I'll be compiling a list of outstanding issues for each subsystem" ...
pd4d10 commentedon May 4, 2021
Can confirm this issue has been fixed with all these paths:
Tested versions:
v12.22.1
v14.16.1
v15.14.0
v16.0.0
Trott commentedon May 4, 2021
As this appears to be fixed on all supported versions, I'm going to close it. Of course, if that's wrong and it's still an issue somewhere, please comment or re-open.
Trott commentedon May 4, 2021
Oh, wait, no, there's still one problem left, right?
require(".\\..") // throwspd4d10 commentedon May 4, 2021
Nope, it's just quoted from the original post.
All cases do not throw errors