Discussion to improve reliability on Windows

[veljkoz]

This line:

global-prefix/index.js

Line 57 in 49684bd

prefix = process.env.APPDATA

//...
if (isWindows()) {

    // c:\node\node.exe --> prefix=c:\node\

    prefix = process.env.APPDATA

      ? path.join(process.env.APPDATA, 'npm')

      : path.dirname(process.execPath);

  } else {
//...

It would've give proper results without assuming the npm is under the APPDATA, i.e. if it's just:

prefix = path.dirname(process.execPath);

Is there any reason for assuming the npm runs under the APPDATA path?

Currently, this gives back the wrong prefix on Windows with nvm (node v8.11.1; nvm 1.1.5)

[veljkoz]

Result of #5, as pointed by @doowb ... I will investigate some more tomorrow... thanks

[doowb]

This PR added the APPDATA check and gives an explanation as to when it should be used. It basically says that if someone re-installs npm using npm install npm --global then the node_modules will go into that APPDATA folder instead of process.execPath.

So depending on how you've installed npm (bundled with node, which nvm does, or through npm itself) the path will be different. There might be a way to check this, but I don't know if it will slow it down. You can also set the prefix in .npmrc files in your home directory or a local directory if you need more control over the prefix.

[doowb]

I reopened this for discussion because after thinking about it, I think it would make more sense to take advantage of the logic we already have for checking the .npmrc files. This would then remove the need for checking APPDATA at all. If someone needs to change the path to APPDATA, then that can be done using PREFIX or .npmrc.

I think the most likely place to find the node_modules will be where npm is executing so that would be process.execPath (since this falls back to what npm is doing). Also, since npx was released, this has caused some issues that we might be able to also fix.

[veljkoz]

If in doubt, maybe it would be a good idea to compare with the results of module.paths and return the first match?

[veljkoz]

I just tried to install older npm via nvm, then update it using npm install -g npm and still it installed it next to the nodejs (C:\Program Files\nodejs), which is not surprising given that the:

npm config get prefix -g
outputs

C:\Program Files\nodejs

I'm now really unsure for the github docs on npm pointed out in #5 -> here... how does one install the global modules under the APPDATA? I can't seem to replicate this... (without explicit tampering of global env, of course).

[jonschlinkert]

Any thoughts on what our best option is? I can try to implement a fix if we have consensus on what should be done.

[jonschlinkert]

@veljkoz @doowb friendly reminder... I'm working on these now if you have any suggestions.

[doowb]

After reading through this again and considering the referenced docs have moved, it seems like using process.execPath might be the best bet or looking to see if npm is doing anything differently now. I'm wondering if the process.execpath didn't work before because whatever was using global-prefix was executed through node directly instead of through npm which might show a different path.

I think I've looked around to figure out if nvm sets any environment variables to indicate where npm is installed but I didn't find anything at the time.

If you figure something out and want me to do some testing on windows, I have a laptop I can use.

[veljkoz]

Agreed - I'd vote to revert the d8d1afb

The other approach would be to use modules.paths[0], but I have a feeling like it wouldn't be "future-proof"...

[jonschlinkert]

Agreed - I'd vote to revert the d8d1afb

Perhaps we can just do fs.existsSync() on the path returned from path.dirname(process.execPath) and return it if it exists. Otherwise, continue with the other logic?

[wuwb]

not work with system link which nvm made to link the default node install path and the specific version node path.