Release: npm@6.10.1

A new version has been released! You can install it with npm i -g npm@latest or try it out with npx npm@latest ...

This release fixes a few annoying issues that y’all have reported on here that I wanted to call out.

The first is that a security fix to chownr resulted in Darwin users being bitten by EISDIR errors in some cases. Special thanks to @godmar for tracking down the root cause of that.

The second is that Visual Studio 2019 support is added with the update to node-gyp. Since node-gyp is used in a lot of npm’s submodules, it was a bit of a chore to get it all wrapped up. Thanks to @irega and @shadowspawn for helping to get that over the finish line.

The v6 line is moving into bugfix and LTS mode while we get to work on the tree-managing refactor for v7 which will improve npm link, make package-lock.json files more consistent, and make workspaces trivial to implement, and assist in integrating tink. Expect a proper roadmap post in the next week or so, and relatively modest weekly-to-biweekly releases to fix bugs in npm v6 for stability and security, but not much else.

v6.10.1 (2019-07-11):




This addresses the EISDIR issue only. The reason for my involvement were the yearlong issues I and many others are having with EACCES errors either under /usr/local or in ~/.npm.

The EACCES issues people are invariably having under Linux + MacOS default install conditions are still present due to pacote #174 and the pollution of system folders due to pacote #175 is also still present. (And given the limited nature of my testing, there may be more defects.) This is evident by the number of posts in this forum complaining about EACCES errors.

The (IMO, prematurely) ratified RFC 012 running as root may address this issue in the future but violates local filesystem standards and conventions.

I note that as of the status quo, even @isaacs 's instructions in above post to install with npm i -g npm@latest will not work under default install conditions - it will work only for those people who have taken steps in changing permissions, changing prefixes, and/or using a version manager such as n or nvm (and even then they will sometimes fail…)

I would urge the npm maintainers to address this longstanding issue with the goal that someone who goes to the website and follows the instructions there ends up with a usable node/npm installation out of the box, which to put it nicely is not an unreasonable goal.

I’ll dig into pacote issues for the next release.