-
-
Notifications
You must be signed in to change notification settings - Fork 32.2k
Description
- Version: 8.9.3
- Platform: Linux
- Subsystem: module loading
From #9673:
--preserve-symlinks does preserve symlinks for all require() calls, but strangely not that of the entry.js file passed on node's command line.
This still seems to be the case today: it is impossible to get node to preserve symlinks for the entry point file. A quick demo of today's behavior:
// a.js
console.log("problem");
// entry.js
require("./a");
// app/a.js
console.log("no problem");
symlink app/entry.js -> entry.js
Then run node --preserve-symlinks app/entry.js
.
What I expected: "no problem" printed
What actually happens: "problem" printed
--
This is a problem for me because I am supporting node integration with bazel (Google's open source build system), and bazel generates binaries by building all the files, and creating a symlink tree for each binary that gives it access to all the files it needs; our bazelled node binaries need --preserveSymlinks
so that they resolve modules relative to the symlink, and not to the target of the symlink. While we've worked around the problem, our workaround breaks require.main
and module.parent
among others, so code that works under vanilla node won't work in our bazelled binaries. The exact details are documented here: https://github.com/dropbox/rules_node#node_binary - the BAZEL_NODE_MAIN_ID
hack is our workaround, which imo is rather ugly.
If either:
a) --preserve-symlinks applied the same to the entry point as all other modules
b) there was an extra flag to enable the same symlink preserving behavior for the entry point
Then we could remove this hack and have better compatibility with existing npm modules.