Windows. Incorrect Module.id with mounted network disk

[tsofist]

• Version: v6.2.1, v6.2.0
• Platform: Windows 10, x64

Steps:

• Mount network drive V:\ = \\CASTOR\
• Install any npm-package (e.g. ajv) to \\CASTOR\scope\
• Launch locally installed node with cwd: V:\scope\ (or launch node from network disk: V:\scope\node.exe)
• Write:require("ajv"); console.log(Object.keys(require.cache)[0])

Output
node v6.1.0 (and previous): V:\scope\node_modules\ajv\lib\ajv.js
node v6.2.0 (and v6.2.1): \\CASTOR\scope\node_modules\ajv\lib\ajv.js

process.cwd() in all versions: V:\\scope

[mscdex]

Can you launch node with --preserve-symlinks and try again? I suspect 95b7560 is the culprit.

[tsofist]

Yes, with --preserve-symlinks it works correctly

[mscdex]

/cc @jasnell

[joshgav]

/cc @orangemocha

[tsofist]

I found similar problem with __filename and __dirname.
node v6.1.0 (and previous): V:\scope\main.js
node v6.2.0 (and v6.2.1): \\CASTOR\scope\main.js

Should I write a new issue for this?

[bzoz]

b488b19 is responsible for this - it changed how fs.realpath works. It landed in v6.

At the same time change to how modules filenames are resolved was introduced in de1dc0a. It switched from fs.realpath to path.resolve. Those two changes together made module filenames resolve as before realpath implementation change.

Now 5d38d54 put change from fs.realpath to path.resolve behind --preserve-symlinks switch. And so, instead of having this issue with v6.0, with fs.realpath change, we have it now. It is just another effect of fs.realpath change which is documented as breaking.

I don't know if we should fix this. Old realpath implementation on Windows didn't check if the drive itself is a "symlink" - mapped network share or effect of callingsubst. IMHO current implementation is correct. If needed, one can use --preserve-symlinks to make modules file name resolve as they used to before. Alternatively, one can use require.resolve to get the filename used as keys to require.cache.

Of course, we could also try to fix this. For Windows, we could make require fall back to old realpath implementation if new one gives filename on different drive or on a network share. The question is, should we do this?

[tsofist]

I wrote this module (t.js):

console.log(
    "__filename:      " + __filename + "\r\n" +
    "__dirname:       " + __dirname + "\r\n" +
    "path.resolve():  " + require("path").resolve() + "\r\n" +
    "module.id:       " + module.id + "\r\n" +
    "module.filename: " + module.filename
);

Run node from V:\Work\IDEA\projects\efrond\nas\~ mount from \\CASTOR-VSRV\Development\Work\IDEA\projects\efrond\nas\~

Output
node v5.9.1:

__filename:      V:\Work\IDEA\projects\efrond\nas\~\t.js
__dirname:       V:\Work\IDEA\projects\efrond\nas\~
path.resolve():  V:\Work\IDEA\projects\efrond\nas\~
module.id:       V:\Work\IDEA\projects\efrond\nas\~\t.js
module.filename: V:\Work\IDEA\projects\efrond\nas\~\t.js

node v6.0.0:

__filename:      V:\Work\IDEA\projects\efrond\nas\~\t.js
__dirname:       V:\Work\IDEA\projects\efrond\nas\~
path.resolve():  V:\Work\IDEA\projects\efrond\nas\~
module.id:       V:\Work\IDEA\projects\efrond\nas\~\t.js
module.filename: V:\Work\IDEA\projects\efrond\nas\~\t.js

node v6.2.1:

__filename:      \\CASTOR-VSRV\Development\Work\IDEA\projects\efrond\nas\~\t.js
__dirname:       \\CASTOR-VSRV\Development\Work\IDEA\projects\efrond\nas\~
path.resolve():  V:\Work\IDEA\projects\efrond\nas\~
module.id:       \\CASTOR-VSRV\Development\Work\IDEA\projects\efrond\nas\~\t.js
module.filename: \\CASTOR-VSRV\Development\Work\IDEA\projects\efrond\nas\~\t.js

node v6.2.1 --preserve-symlinks:

__filename:      V:\Work\IDEA\projects\efrond\nas\~\t.js
__dirname:       V:\Work\IDEA\projects\efrond\nas\~
path.resolve():  V:\Work\IDEA\projects\efrond\nas\~
module.id:       V:\Work\IDEA\projects\efrond\nas\~\t.js
module.filename: V:\Work\IDEA\projects\efrond\nas\~\t.js

I do not think it's ok.
Information about the module becomes grease, moreover, it is not obvious.

[bzoz]

There is more discussion about this real path issue here: #7175.

[Loghorn]

My situation is even worse, if possible. I'm using Visual Studio Code to develop and debug node projects.
I frequently switch project, so to simplify my workflow I use subst to make the root of the project act like a disk drive: this makes path shorter (with the side effect of reducing the Windows long path problem) and allows me to quickly change project simply by typing the drive letter.
I recently upgraded to node v6.3.0 and I can't set breakpoint in VS Code anymore, because the modules are loaded with their 'real' path instead of the substituted one.
--preserve-symlinks doesn't resolve the situation: the main file loading ignores the flag and because all subsequent require use a relative path all the files are loaded with the real path, making impossible setting breakpoints (that needs the absolute path of the file)