Skip to content

Unable to install packages where symlinks are supported but unavailable #4334

jaraco opened this Issue Dec 17, 2013 · 4 comments

4 participants

jaraco commented Dec 17, 2013

I'm trying to install node packages in Linux VM hosted by VMWare and Vagrant on Windows. The project I'm developing is contained on the host and mounted in /vagrant on the Linux VM. Due to a limitation in VMware, symbolic links in the mounted directory will fail with an I/O error.

Because npm is on Linux, it assumes symlinks are available and tries to use them when invoking npm install, but then the command fails when symlinks are used (presumably to optimize the install).

Due to #775, it's not possible to customize the location of the node_modules path. If that feature were present, it would be possible to store the node_modules in another path (such as ~/node_modules or ~/{project}/node_modules or similar, which is outside of the mounted path that disallows symlinks).

Is there a way to disable the use of symlinks during install or to otherwise not install to ./node_modules in these environments?


@isaacs I'm also running into this issue. In #775 you said every use case was covered, but that's clearly not the case when using something like shared folders on a Windows host/Linux guest. Symlinks are available but do not work.

Not only do some packages fail in this scenario, there is a massive performance penalty caused by a large number of files in the shared folder. If we could have NPM installed to a different directory, that fixes the issue. As it stands, I have to do some really awful hacks to get around this.


@brandonwamboldt Exact same use case here (Vagrant on Windows). It just seems ridiculous that I have to make some crazy bash alias for npm all because npm won't let me chose where to install as... I might hurt myself. We're all consenting adults here.

Anyways. the major issue I've run into:

  1. symlinks (hacky workarounds abound). no-bin-links might work, but I wouldn't know as npm install always fails because...
  2. Windows limitations on the length of paths.
  3. Speed; having all of those files shared slows things down a ton.

See this comment, which is more or less the official stance of the team when it comes to running npm on filesystems shared between vms and host OSes. If the filesystem says it supports symlinks, but it really doesn't, there's not a lot we can do.

@othiym23 othiym23 closed this Sep 22, 2014
jaraco commented Sep 22, 2014

I believe you're mistaken here. It's not that "there's not a lot [the team] can do", but rather the team is not willing to accept that as issue worthy of being addressed.

I can think of several solutions, some of which have been proposed before.

  1. Add a config option to disable the use of symlinks.
  2. Allow the location of the packages to be user-configured (#775).
  3. Detect and handle the failure to create a symlink on a system which appears to support symlinks but doesn't.
  4. Update the documentation to explicitly note that npm isn't supported in this type of environment.
  5. Solicit and accept pull requests or patches to address the issue.

So actually, there is a lot that the team could do. Instead, the team appears to have declared that this issue should not be addressed and that the defective behavior will remain indefinitely.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.