-
-
Notifications
You must be signed in to change notification settings - Fork 185
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
doesn't support $HOME/.node_modules
or $HOME/.node_libraries
#163
Comments
I think you'll need to set the |
Nope, doesn't seem to help: $ nodejs -e 'console.log(require.resolve("lodash")); require("resolve")("lodash", { preserveSymlinks: true }, console.log);'
/mnt/…/nodejs/modules/lodash/lodash.js
{ Error: Cannot find module 'lodash' from '.'
[…] |
To clarify, with "explicitly resolve the returned path" I meant I have to |
(Possibly related to #122) |
preserveSymlinks doesn't seem to work on Windows Symbolic link or Junction. Is there a problem with the implementation in the module ? |
@myuseringithub does node itself work with windows symlinks? |
I reproduced the problem and took an strace capture. The diff shows what really happened vs. what I'd expect to happen: -stat64("/mnt/…/nodejs/modules/node_modules/lodash/package.json", …
+stat64("/mnt/…/nodejs/modules/lodash/package.json", …
stat64("/mnt/…/nodejs/node_modules/lodash/package.json", …
stat64("/mnt/…/node_modules/lodash/package.json", …
stat64("/mnt/node_modules/lodash/package.json", …
stat64("/node_modules/lodash/package.json", … It seems |
@ljharb Yes, I use symbolic link of type Junction, as it allows me to create symlinks that are supported between the host machine (Windows OS), and the Docker container (Linux OS) which I'm running the app on. In my setup both the host machine and container use JS scripts to run the project. |
I'm unclear on what needs to be done here. Could anyone provide a repro repo, or better, a failing test case? |
Bug demo in GitLab Actions: https://github.com/mk-pmb/browserify-resolve-symlink-163 |
@mk-pmb thanks - is there any way to repro it on the command line? When i run
|
@mk-pmb ah! resolve 1 has Try setting |
Yes, if you run
You'll need GNU coreutils 8.21 or later installed. Ubuntu ships it by default, so I use that in the GitHub Actions.
Done in the |
Seems like it's good! Does that mean this can be closed? |
The first two tests are the part that had been easy to fix ever since. The bug in my opening post is reproduced in the 3rd test case, and it still fails:
|
I see now why you thought it was about the pify path. I'll clarify the tutorial in the demo readme. |
the words "global module" concern me a bit; global modules aren't requireable or resolveable (unless you use the deprecated NODE_PATHS env var, which this package intentionally doesn't support and likely never will). Can you elaborate on that one? |
I'm not sure if my naming of "global" in the example is correct. I'm also not up-to-date on the deprecation. If you can determine the cause and conclude that the difference in the 3rd example is out of project scope, we shall instead check whether the readme could use better info about why. |
However, what I can provide, is to say I didn't write anything about |
In the no-preserve-symlinks, I'm able to cd into |
I expect it will consider |
@mk-pmb it doesn't and shouldn't, no - Either way, in your repro repo there's no |
What do you mean by ".node_modules is never a thing."? It's still in current node master: lib/internal/modules/cjs/loader.js if (homeDir) {
ArrayPrototypeUnshift(paths, path.resolve(homeDir, '.node_libraries'));
ArrayPrototypeUnshift(paths, path.resolve(homeDir, '.node_modules'));
} Which explains why on GitHub Actions, node.js can successfully resolve all examples. (See logs, or example output in readme).
The resolving chain is (all inside repo):
|
whoa, that was not a thing I was aware of.
|
In other words, this issue has nothing to do with symlinks - it's about some kind of special (note that "global" means |
$HOME/.node_modules
For history's sake: nodejs/node@5a49f96#diff-cdd77182e73349d6c83fbbce1cccf6f15972fbece4dbd9c52eececf1ca3bfcd5R307-R308 is in every node version since basically ever. |
$HOME/.node_modules
$HOME/.node_modules
or $HOME/.node_libraries
I updated my test project;
Update: Today I learned that my global modules being require()-able system-wide is just accidential. The node design concept seems to understand |
indeed; global things aren’t supposed to be requireable. |
The current workaround for this is to pass |
…s,libraries}` Note, this is a rarely used feature that should be aggressively avoided, but it‘s important to minimize gaps between node and this package. Fixes #163
…s,libraries}` Note, this is a rarely used feature that should be aggressively avoided, but it‘s important to minimize gaps between node and this package. Fixes #163
…s,libraries}` Note, this is a rarely used feature that should be aggressively avoided, but it‘s important to minimize gaps between node and this package. Fixes #163
Hi, thanks for this module!
It seems to have trouble finding my packages, though:
So
require.resolve
was able to find it, butresolve
wasn't. However, it works when I create a symlink/mnt/…/nodejs/node_modules
tomodules
.Update: Work-around: It also works when I pass option
{ paths: [process.env.HOME + "/.node_modules"] }
Update 2: However, in that case I have to then explicitly resolve the returned path in order to get the exact same result.
The text was updated successfully, but these errors were encountered: