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

[klovadis]

After installing node using the .msi installer, node is being installed into the "Program Files (x86)" folder, where node does not have any permissions. Thus when using npm, you cannot install global modules, because node cannot write into the "Program Files (x86)\nodejs\node_modules" folder.

Instead, node.exe should store and look for npm modules somewhere in the user %appdata% folder.

[isaacs]

That is by design. If you start a cmd shell as administrator, then you'll have escalated permissions, and be able to write to the global folder. Or you can do npm config set prefix C:\blahblahblah to point it somewhere else.

That being said, I'm not sure of the proper customs on Windows. @igorzi @piscisaureus care to weigh in?

[piscisaureus]

@isaacs I actually agree with @klovadis

[igorzi]

Oops, accidentally closed the issue.

[igorzi]

yeah, %programfiles% is probably not the right place for node_modules, also because it gets uninstalled when users upgrade to newer versions of node. I do think that it's nice that installation of global modules requires elevated context.

[chowey]

The npm_cache is already in the user's folder. This is actually the more critical folder for npm. If the intention is to share modules between users on the same computer, then both npm_cache AND node_modules should be in Program Files.

Personally I feel it is more "Windows 7-ish" to keep npm_cache in the user's folder, and to put global node_modules in %appdata%.

If you are creating a node.js app, then you should install modules local to that app, which will then run fine from any user that can access that app's directory.

[isaacs]

@piscisaureus Ok, I'm fine with it either way. The tricky thing would be that %appdata%\npm isn't in the %Path%, so if you npm install vows -g, then you won't be able to run vows afterwards.

Can we update the MSI to add %appdata%\npm to the %Path% as well?

[piscisaureus]

Actually I am more for installing into the user folder.

(Yes I know I change my opinion all the time. I should run for president.)

[piscisaureus]

Now that we're at it, npm-cache should not go into the user's root folder. Stuff it in %appdata%.

[isaacs]

The question of where npm defaults the cache and global prefix on windows for a manual install really should be an npm issue, not a node issue.

Nothing here makes me think that we should change where the msi-installed npm gets dropped, especially since you probably do want that updated if you update node.

The problem I see with putting it in %appdata% is that the whole point of global installs is to install things that can be used from the command line. If %appdata%\npm isn't in the %Path%, then it's not a good choice as a default, but of course, all that's configurable pretty easily.

We could always have the MSI modify the %Path% to put %appdata%\npm there, in front of %ProgFiles%\node.

[klovadis]

Correct me if I'm wrong, but my npm installs also failed when I used the command prompt and npm with administrator privileges. Only after manually granting write permissions for the nodejs folder to the current user npm ran successfully. Afaik by default you need elevated permissions (granted i.e. during the installation procedure) to write into the Program Files folder.

[isaacs]

Someone needs to write sudo for windows ;)

How about this as a plan:

1. Leave the npm default global prefix as it is, and have the msi drop npm into the same folder as node, as we're doing now.
2. Write prefix = <whatever> to %ProgFiles%\node\node_modules\npm\npmrc
3. Add <whatever> to the %Path% environ in front of %ProgFiles%\node.

The effect of this will be:

1. Global installs will work out of the box, without elevated perms, and will add things to the command line path, but will not be requireable.
2. npm install npm -g will fetch a newer version of npm, which will override the node-installed one, so self-update will work.
3. Installing a new version of node will install a new builtin version of npm.
4. Manually dropping npm in the same folder as node.exe will work as it does now, so people who don't use the MSI don't have to do anything special.

Does that meet everyone's needs?

[chowey]

What do you mean, "Write prefix = <whatever> to %ProgFiles%\node\node_modules\npm\npmrc"? Is that the npm config file? It doesn't seem to exist in my installation.

Otherwise, I think it's a good solution. The <whatever> should be %appdata%\nodejs or some such.

[isaacs]

Fixed in v0.6 branch, publishing very soon.

[michahell]

Reading this discussion and trying to figure out why installing in a user folder was ever thought of as the better choice... My use case is that another user (administrator also) is not be able to invoke globally installed modules installed by another administrator on the same machine (by default). That seems wrong to me. This also does not happen in the case of OSX, as far as I know.

npm/npm#5753

[nicksoph]

Windows - At Install create a globally accessible folder as Admin, this will be the global store and although it requires elevated privileges to create and assign permissions, no admin is needed thereafter.
In the simplest and least secure scenario this folder would simply be given change/read to everyone but if you wish to demarcate between reading and writing on the folder create local groups with differing permissions on folders and assign users to appropriate groups. In this case if the installation program asked where the folder should be created then with elevated privileges the folder was checked for suitablity (if its not on an NTFS partition - then none of this is relevant and the problem would not arrrise), the install would then either create and set permissions or just set permissions, for the most users I suggest a default of (Admin: full control, Authenticated Users: change) would be suitable.

[joewood]

In terms of real-world usage and requirements, there's really three levels of installation - global, shared and local. For Linux and OSX a global install is globally available on the machine, regardless of who's logged in (so it needs sudo). On Windows global really means "shared" - which means global for the user and accessible outside of a repository, but not globally on the machine (so no elevation is required).

I'm happy with the Windows behavior, as most cases people use -g when they really want shared and not globally on the machine. I would argue that npm would benefit from having a third level of installation that requires sudo or elevated permissions for Windows (maybe keeping that as --global) and changing the current behavior of global now in Windows and call it --shared. This would make it consistent across platforms and the need to use sudo less common for OSX and Linux users.