Support environment variables in .npmrc's "prefix" setting

[mk-pmb]

I traced the strange behavior of resolve-package to a problem in this package:

My node code:

console.log(require.resolve("lodash"));
require("get-installed-path").getInstalledPath("lodash").then(null, console.log);

Output:

/mnt/…/nodejs/modules/lodash/lodash.js
Error: get-installed-path: module not found "lodash" in path /home/mk/${HOME}/lib/node_modules/lodash
    at fs.stat (/mnt/basecamp/app-res/nodejs/modules/get-installed-path/dist/index.js:98:23)
    at FSReqWrap.oncomplete (fs.js:152:21)

When I change the prefix setting in my .npmrc from ${HOME} to ${HOME}/foobar and copy my ~/.node_modules symlink there, the error message adapts to
Error: get-installed-path: module not found "lodash" in path /home/mk/${HOME}/foobar/lib/node_modules/lodash

I wonder though, where does the /home/mk come from if the ${HOME} wasn't replaced?

[tunnckoCore]

Yeaaa... I dont like the implementation of the paths option. Can you try the sync one? Is there the same problem?

I can look at that bug in the coming days, because im on vacation.

It feels like it's a bug here, but if not it is on the global-modules side.

[mk-pmb]

$ nodejs -p 'require("get-installed-path").getInstalledPathSync("lodash");'
/mnt/…/nodejs/modules/get-installed-path/dist/index.js:164
    throw new Error(msg);
    ^

Error: get-installed-path: module not found "lodash" in path /usr/lib/node_modules/lodash
    at Object.getInstalledPathSync (/mnt/…/nodejs/modules/get-installed-path/dist/index.js:164:11)
    at [eval]:1:31
    at ContextifyScript.Script.runInThisContext (vm.js:50:33)
    at Object.runInThisContext (vm.js:139:38)
    at Object.<anonymous> ([eval]-wrapper:6:22)
    at Module._compile (module.js:652:30)
    at evalScript (bootstrap_node.js:466:27)
    at startup (bootstrap_node.js:167:9)
    at bootstrap_node.js:612:3

In case it's a 3rd party bug, g-i-p should add a hint to the error message which module suggested the broken path.

PS: The guess is almost right, minus the ${HOME}/ part. /home/mk/lib/node_modules/lodash happens to be a valid alias to my lodash module, so fs.realpath()ing that would yield the correct solution. I guess it's by random chance though, since I believe the correct derivation is to go via the ~/.node_modules symlink.

[tunnckoCore]

hm, strange. I know it's the same but try $HOME? otherwise it more and more feels to like a problem with symlinking and prefix resolving which is inside global-modules and global-prefix packages.

[mk-pmb]

with prefix = $HOME:

$ nodejs -p 'require("get-installed-path").getInstalledPathSync("lodash");'
[…]
Error: get-installed-path: module not found "lodash" in path /home/mk/$HOME/lib/node_modules/lodash
[…]

with the prefix setting commented out in .npmrc:

$ nodejs -p 'require("get-installed-path").getInstalledPathSync("lodash");'
[…]
Error: get-installed-path: module not found "lodash" in path /usr/lib/node_modules/lodash
[…]

global-modules seems to correctly identify my global modules path:

$ nodejs -p 'require("global-modules")'
/usr/lib/node_modules
$ ls -A /usr/lib/node_modules
npm

However, it's a good thing you reminded me about that stale npm. I generally don't install modules globally, but the way I install node.js causes an old npm to linger there.

Is g-i-p supposed to be able to find files as well? If so, the old npm seems to confuse it:

$ nodejs -p 'require.resolve("npm/README.md")'
/mnt/…/nodejs/modules/npm/README.md
$ nodejs -p 'require("get-installed-path").getInstalledPathSync("npm/README.md");'
[…]
Error: get-installed-path: module not found "npm/README.md" in path /usr/lib/node_modules/npm/README.md
[…]

Bonus:

$ nodejs -p 'require("get-installed-path").getInstalledPathSync("get-installed-path");'
[…]
Error: get-installed-path: module not found "get-installed-path" in path /usr/lib/node_modules/get-installed-path
[…]

[mk-pmb]

In case it helps, here's the workaround I use for the resolve package which had similar problems.

[tunnckoCore]

Is g-i-p supposed to be able to find files as well?

No, it automatically detects the entry point of a package - the main field in module package.json, based on the resolve-package implementation.

Doh. Okey, i'm at home so debugging can start. Meanwhile can you try the v2.0.3 - nothing serious since then (v3 is dropping nodejs v4 support, v4 is the named exports change), it is the last release before introducing the paths option in #13.

Also, is lodash installed on the cwd (where you execute the nodejs -p)? If so, then it is expected to throw because it does not find it globally nor locally.

[tunnckoCore]

Huh, caught one unexpected behaving of the Sync method. It definitely should try to search locally if it fail to find it globally, but it throws.

edit:
oh, i'm idiot 😆 i was thinking for the resolve-package..

edit2: okey, can you please report the problem in the resolve-package issue tracker? what's the problem that you encountered with it? I definitely can't test all that things because i'm using nvm and don't want to mess the setup.

[tunnckoCore]

For some reason (probably because of using nvm) the global-modules shows me

/home/charlike/tunnckoCore/bore/$HOME/lib/node_modules

when set the prefix in the ~/.npmrc ...

Doh... One more thing is that even that i have node and npm through the nvm, i also have them installed through the OS package manager, because of some other package - probably electron, anyway.. So i can access them throu /usr/bin/node8 - symlink to node-lts-carbon and /usr/bin/npm. That's okey, but it seems that when set the prefix (npm config set prefix $HOME) through the npm (not /usr/bin/npm) it does not appear at the ~/.npmrc, but is listed when npm config ls. The question is where it writes it ;d

Total mess.. Anyway, i'll clean up and report :D

[mk-pmb]

Also, is lodash installed on the cwd[…]?

Nope, cwd was /home/mk and lodash is on /mnt/…/nodejs/modules/lodash/lodash.js. Node can find it via the ~/.node_modules symlink to /mnt/…/nodejs/modules. When I rename the symlink to ~/bogus, node stops finding lodash. When I rename it to ~/.node_libraries, node again finds it, so g-i-p should check that one, too. Not sure about search priorities though.

[tunnckoCore]

Wait. require.resolve throws errors too, because it looks locally. Or at least, it throws here at linux

~/tunnckoCore/baw
❯ npm i -g lodash                                 
+ [email protected]
added 1 package from 2 contributors in 1.538s

~/tunnckoCore/baw
❯ node -p 'console.log(require.resolve("lodash"))'
internal/modules/cjs/loader.js:596
    throw err;
    ^

Error: Cannot find module 'lodash'
    at Function.Module._resolveFilename (internal/modules/cjs/loader.js:594:15)
    at Function.resolve (internal/modules/cjs/helpers.js:30:19)
    at [eval]:1:21
    at Script.runInThisContext (vm.js:91:20)
    at Object.runInThisContext (vm.js:298:38)
    at Object.<anonymous> ([eval]-wrapper:6:22)
    at Module._compile (internal/modules/cjs/loader.js:702:30)
    at evalScript (internal/bootstrap/node.js:539:27)
    at startup (internal/bootstrap/node.js:213:9)
    at bootstrapNodeJSCore (internal/bootstrap/node.js:572:3)

[tunnckoCore]

But anyway. It sounds like a problem in global-modules and with prefix resolving.

Also, i can't really find a way to try and error, and fix that bug, because i'm using NVM.

I'm open for PRs.