Global module installation should fail more rapidly, if sudo isn't used

[pcgeek86]

I'm opening this issue because:

• npm is crashing.
• npm is producing an incorrect install.
• npm is doing something I don't understand.
• Other (see below for feature requests):

What's going wrong?

On Mac OS X 10.12 (Sierra), when I perform a global install without sudo (eg. npm install <package> -g), it takes npm some time to indicate an access failure. Before the "access denied" message is printed, the module dependencies are apparently resolved, rather than immediately failing.

In my opinion, this should fail earlier in the process, if adequate permissions aren't available for a global module installation. I'm not sure what the best solution to this is, as I'm not familiar with the npm source code, but wanted to provide a user story surrounding this.

How can the CLI team reproduce the problem?

supporting information:

• npm -v prints: 4.0.5
• node -v prints: v7.2.1
• npm config get registry prints: https://registry.npmjs.org/
• Windows, OS X/macOS, or Linux?: Mac OS X 10.12 (Sierra)
• Network issues:
  • Geographic location where npm was run:
  • I use a proxy to connect to the npm registry.
  • I use a proxy to connect to the web.
  • I use a proxy when downloading Git repos.
  • I access the npm registry via a VPN
  • I don't use a proxy, but have limited or unreliable internet access.
• Container:
  • I develop using Vagrant on Windows.
  • I develop using Vagrant on OS X or Linux.
  • I develop / deploy using Docker.
  • I deploy to a PaaS (Triton, Heroku).

What's the feature?

Fail early, if user doesn't have proper filesystem access to install Node modules globally.

What problem is the feature intended to solve?

User frustration / wasted time.

Is the absence of this feature blocking you or your team? If so, how?

This is a non-blocking feature. Just an annoyance.

Is this feature similar to an existing feature in another tool?

No.

Is this a feature you're prepared to implement, with support from the npm CLI team?

No.

[legodude17]

You could try npm doctor, which will let you know (new in 4.1.0).

[pcgeek86]

That would require the user to memorize and run a separate command, rather than focusing on their intent, which is to install a Node module globally. Not a very good solution from a user experience standpoint.

[legodude17]

@pcgeek86 I agree, but you could just run npm doctor once, and then be confident that you have the correct setup. Also, having a check early on to check the permissions would make npm install even slower than it already is. I agree that the user experience could be improved, but at what cost?

[pcgeek86]

I'm not sure what the cost would be to improve the UX here. Hopefully it wouldn't cost too much development time, or system resources, to perform a simple check for root access, prior to resolving dependencies and installing them. However, I'm not personally familiar with the npm code base, hence I'm not the appropriate individual to address this. Just filing the UX feedback.

[legodude17]

Ok. Thanks for the feedback. The check could be performed at the start of install but that would take more than a cursory amount of work. I think it would be good to take community feedback before someone puts in the work to make this work (No pun intended).

[pcgeek86]

Cool, I'm just curious why specifically it would take a significant amount of work? From my limited point of view, it would be fairly simple to test for filesystem permissions, validate group membership, or otherwise figure out if the user has root permissions. What part of this validation would require a significant amount of effort? Cheers

[legodude17]

It depends on where you would want to put it. You could probably put a simple check here, or for more work you could make it fit with all of the chaining and the Install class a little farther down.

[npm-robot]

We're closing this issue as it has gone thirty days without activity. In our experience if an issue has gone thirty days without any activity then it's unlikely to be addressed. In the case of bug reports, often the underlying issue will be addressed but finding related issues is quite difficult and often incomplete.

If this was a bug report and it is still relevant then we encourage you to open it again as a new issue. If this was a feature request then you should feel free to open it again, or even better open a PR.

For more information about our new issue aging policies and why we've instituted them please see our blog post.