Nvm-windows: Incorrect installation folder

[Grauenwolf]

My Environment

• [ ] Windows 10

The AppData folder is for data, not executables. This shouldn't be installing there by default, let alone the roaming branch where it automatically gets copied to every machine on the same Windows domain.

[Grauenwolf]

Am I mistaken, or did NVM just put a 400MB node package cache into my roaming profile? As in the set of files that get copied from the domain server every time I log in?

Nope, that's a bug in NPM.

[coreybutler]

The default installation points to the local user appdata directory, not the roaming. While it may be better to have the executable in a different location, all of the node installation files and npm are considered data for NVM (this is an npm design). Again, these are defaults for a reason... you can change them if you don't like them.

I have no idea where you're getting 400MB from. Can you provide more details about your environment?

[Grauenwolf]

On the first point, perhaps the difference is that I'm installing it on a domain-attached computer and you aren't. But either way it is still wrong. AppData is for user settings, not executables.

As for the second point, it is Node itself making that mistake. I'll file a bug with them separately.

[coreybutler]

This isn't "wrong" necessarily, but if it is having adverse effects, I'm happy to consider your use case. I didn't have the same experience with a domain-attached computer, so again, details of the environment would help me understand your specific use case.

For example, if I know what to look for, I can make the next version of the installer domain-aware. In other words, the default installation location could be smarter.

[Grauenwolf]

Here are the baseline recommendations:

• Programs go in %ProgramFiles%, which is usually C:\Program Files.
• On a 64-bit machine, old x86 programs go in %ProgramFiles(x86)%, which is usually C:\Program Files (x86).
• Machine-wide program data, like package caches, go in %ProgramData%, which is normally C:\ProgramData
• User settings that can safely roam from machine to machine go in %APPDATA%
• User settings that are local to a given machine (e.g. ones that contain installation paths) go in %LOCALAPPDATA%.

[aljones]

It is not uncommon for executables to be in appdata. Applications installed using clickonce do it, which is an installer made by microsoft. Chrome does it. Lots of things do it.

[ygra]

@aljones One major reason is this – Installing programs in the user profile may be convenient, but it definitely has security consequences in that any process can modify stuff as it pleases. Note that ClickOnce _does_ install in the user profile but also ensures that assemblies have fewer privileges on the system.

While there are in general use cases for installing applications per-user without needing administrative privileges, it's a very poor default behaviour and Chrome sets a bad precedent here, imho.

[cokobware]

I believe my very recent experience is relevant to the discussion: I recently had a workstation switch. The paths for node_packages in my roaming profile were so deep, that the roaming profile restore that my machine tried to do would fail every time until I blasted away the node_packages folder. These errors popped up in the Windows Event logs. After I did that, my new workstation could finally sync my roaming profile.

[sam3k]

I will agree that installing to roaming causes issues when you work on companies that back up your profile to be used within their networks. For instance, it takes my computer 30 minutes to shutdown and 30 minutes to restart; all due to the npm modules. Unfortunately, AFAIK, this is an issue with NPM itself.

[coreybutler]

As a followup on this:

In general, it is important to note that any version manager is just managing programs. I reiterate a previous comment.... in the sense of NVM, the installed program (node) _is_ the data. How you use it (i.e. npm modules) can contribute to the footprint.

@sam3k is correct that the footprint is definitely related to how npm was deigned, and there's really not much NVM _should_ do for this, nor is there much npm itself can do for this. It boils down to knowing what you're installing, and a package manager of any kind makes it easy to take this for granted. Many folks don't pay attention to the footprint of modules, which is a code/environment quality problem inherent to the open source world. Bottom line, it's up to the community to solve this problem through disciplined coding practices (a far from trivial task). I'm one of many who've advocated this (see npm needs a personal trainer. Point: npm management goes beyond the basic premise of managing which version of node you're running.

@aljones and @ygra both have good points. I don't disagree with them, but I do want to remind everyone that administrative privileges are a necessity in order to make symlinks work. This is the core principle of how NVM for Windows works.

@cokobware has what I believe to be a common problem in enterprise environments. The bottom line is npm was not designed for easy portability at scale. One instance of node+npm is already quite heavy, let alone adding multiple versions. Regardless of how the data/files move from workstation to workstation, there are just so damn many of them that it's going to take a while. The options are to use Windows roaming profiles, zip everything up and transfer manually, or re-download from an npm registry. No matter how you spin it, syncing a workstation is just going to take time to get all the bits into the right place.

The future of NVM for Windows (as of now) will likely remain focused on node version switching. I may even change the project name to reflect that. It will continue to provide an installer with common defaults, but it will still be up to the organization/developer to override these defaults in a manner appropriate for their organization. I see node version management as a distinctly different problem from npm footprint management, though I'm experimenting with ways in which NVM4W can provide hooks for better npm management.

[agustinustan]

Please follow @Grauenwolf suggestion and these references: deployment guide, CSIDL and Environment Variables

• symlink %USERPROFILE%AppData to %PROGRAMFILES% or %PROGRAMFILES(X86)% is a bad idea. Problem in the multiple user (Ownership issue. Other user can not access the link).
• Program nvm suppose to be stored in %PROGRAMFILES% or %PROGRAMFILES(X86)%.
• nodejses repository supposed to be stored in %PROGRAMDATA% since the scope is all users.
• active nodejs link supposed to be stored in %LOCALAPPDATA% since the scope is per user.

[Grauenwolf]

NVM can't be installed in %PROGRAMFILES% because of other bugs. If you put it in a folder that has a space in its name, the install command fails.