Windows: NPM globalconfig path is a non-global, user-specific location #5753

Closed
splatteredbits opened this Issue Jul 22, 2014 · 12 comments

Comments

Projects
None yet

The npm globalconfig option is set to a user-specific location. In our environmet, node runs as an unprivileged user. We use DSC to configure our machines and run our automated setup scripts, which runs as the SYSTEM account. Because the account running node and configuring node are different, I can't configure node system-wide to use a specific prefix.

Steps to Reproduce:

  1. Install Node on Windows
  2. Run npm config ls -l --global and note that the globalconfig options points to the current user's APPDATA directory.
  3. Log in as another user, and run npm config ls -l --global and note the globalconfig options points to that users's APPDATA.

Thus, I have no way of configuring NPM for all users across the entire computer.

OK. Turns out when you run npm config ls -l, you have to use the --global flag. When I view the config across user accounts with the --global flag, then I see a global value for my configuration. N00b.

OK. This is actually an issue. On a fresh machine where I install Node.js, I'm seeing this in the %ProgramFiles%\nodejs\node_modules\npm\npmrc file:

prefix = ${APPDATA}\npm

This default makes the --global flag effectively useless, as it sets all global configuration to be in the current user's APPDATA directory.

PS H:\> npm config ls -l --global
; cli configs
global = true
long = true
registry = "https://registry.npmjs.org/"
user-agent = "npm/1.4.14 node/v0.10.29 win32 x64"

; builtin config undefined
prefix = "C:\\Users\\username\\AppData\\Roaming\\npm"

; default values
globalconfig = "C:\\Users\\username\\AppData\\Roaming\\npm\\etc\\npmrc"
userconfig = "C:\\Users\\username\\.npmrc"

Because of this default, I can't actually change prefix to a different value, because using the --global switch operates on the npmrc in my appdata directory, not the global one that ships with npm.

Once I remove the prefix option from %ProgramFiles%\nodejs\node_modules\npm\npmrc, I get more sensible options:

PS H:\> npm config ls -l --global
; cli configs
long = true
registry = "https://registry.npmjs.org/"
user-agent = "npm/1.4.14 node/v0.10.29 win32 x64"

; default values
globalconfig = "C:\\Program Files\\nodejs\\etc\\npmrc"
userconfig = "C:\\Users\\ajensen\\.npmrc"

@iarna iarna added the support label Sep 17, 2014

bsauls commented Nov 26, 2014

The prefix value that you give does not exist in my fresh install. There is no "prefix =" listing at all in the actual file at C:\Program Files (x86)\nodejs\node_modules\npm.npmrc. However, on listing the global settings with npm config ls -l --global, the listing matches your above with the exception of "(overriden)" at the end of the prefix path, since the user's npmrc overrides the corresponding values in the global npmrc, and I edited mine to point to:prefix = "C:\Program Files (x86)\nodejs".

Contributor

smikes commented Jan 21, 2015

Is this still a problem for you?

I think that part of the issue here is that global means "across all modules" and stands opposed to "for this module only".

For example, when I use npm I am using nvm to switch between versions of node and npm, and npm install --global actually winds up installing somewhere under ~/.nvm/versions... -- this directory is only visible to me, and not shared with other users.

In any case, it sounds like you are trying to configure npm such that a globally installed module is available to all users on a specific machine. npm works this way by default on Unix-like machines, where the bin scripts specified by package.json are installed to /usr/local/bin or similar. If this is not working on Windows, then it should be classified as a bug.

When you reported this, you were using a then-current version of npm, but there have been a lot of improvements to npm since 1.4.14. Can you try updating your npm installation and let us know if the problem is still present in npm@latest

To update npm on Windows, follow the instructions here: https://github.com/npm/npm/wiki/Troubleshooting#upgrading-on-windows

We are trying to clean up older npm issues, so if we don't hear back from you within a week, we will close this issue. (Don't worry -- you can always come back again and open a new issue!)

Thanks!

Contributor

othiym23 commented Feb 20, 2015

The location of globalconfig on Windows has done some changes, and is set via the npmrc file that the Node Windows installer drops into the npm folder on install. There's also some support inside npm for moving that configuration along when npm is used to upgrade itself that was broken for a while, but has been fixed for the last four months or so (one of the weirdest tests in npm makes sure that stays working). At this point I think we do have it pretty much sorted out, and so @smikes's advice about upgrading is sound, and I can close this issue as resolved.

@othiym23 othiym23 closed this Feb 20, 2015

@michahell michahell referenced this issue in nodejs/node-v0.x-archive Jan 29, 2016

Closed

Move npm files into %appdata% on windows 7 / vista #2207

This is definitely still an issue, and it is still the case for node stable v5.5.0 with a fresh install. Installing packages """globally""" installs packages in C:\Users\AppData\Roaming\npm\.
Also the prefix is definitely accounted for in C:\Program Files (x86)\nodejs\node_modules\npm.npmrc in a fresh v5.5.0 install.
Why isn't anybody experiencing issues with this? it seems kind of stupid. The issue is indeed resolved by changing the default prefix: ${APPDATA}\npm to a more sane C:\npm or something.

Globally doesn't mean for "all users" it means accessible throughout the system since it's being injected in the sys env.
to use npm without (annoying) elaborated user it's way more convenient if it keeps installing the modules on the users local folder!

jmtvms commented Jul 6, 2016

I just executed the command

npm config set prefix "%ProgramFiles%\nodejs"

And now all users can use the installed node modules.
Make sure that the folder %ProgramFiles%\nodejs is in the path system wide.

to undo the change just execute

npm config rm prefix

Removing the config make it goes back to the default settings.
Reminder: Consider removing all packages installed on the %ProgramFiles%\nodejs before changing back the configuration. Or you may have some conflicts on the packages.

aTable commented Jul 21, 2016

I've run into this issue while provisioning a CI server on Windows and it was made so much more difficult than it should be imo.

I'm sure there's a reason why npm considers global to be on a per user basis however, I'd like to see @jmtvms solution above ship with node + npm by default as the current prefix of "%AppData%\npm" causing unnecessary issues.

yorambi commented Jan 7, 2017

npm global directories should use the %ProgramData%\nodejs folder as per KNOWNFOLDERID and CSIDL %APPDATA% folders are PERUSER "Folder Type" and not a global ones.

Many applications on windows are using this global folder. And yes only Administrators can write there but anyone can read.

See git for example installer: honor %PROGRAMDATA%\Git\config #50 ...

alexangas commented Feb 28, 2017

@smikes This is still an issue...

  • using npm config set saves the config to c:\users\%username%\
  • using npm config set --global saves the config to c:\users\%username%\AppData\Roaming\npm\etc

There doesn't seem to be a way to do this at the machine level.

npm on my machine will not let me set the AppData\Roaming\npm as the config prefix so none of my packages are installed there but in my project directory which causes a mess with all of the .cmd files etc. When I run npm config get prefix -g it just shows me whichever directory I'm currently in, then when I run npm config set prefix "${APPDATA}/npm" -g it shows that it does "something". Then when I run npm config get prefix -g again, it still just shows me the folder I'm currently in. It does not change my npm prefix directory to the AppData directory. The npm folder in that directory is empty and never gets anything added to it when i use the -g when installing packages. Anyone have an idea? All other workstations work fine but this one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment