Announcing NPM 6

npm has eroded so much of my trust that I am hesitant to switch back to it (from yarn) any time soon.<p>I&#x27;ve tried npm out every few months (since npm 3), and have consistently run into infuriating bugs or unexpected behaviors.<p>Much of it has been fixed over time, but the frequency and duration of these issues is concerning—and, I think, points to architectural deficiencies being the root of the problem. For example:<p>* npm 5.0.0—5.7.0 didn&#x27;t play nice with git-based dependencies (<a href="https:&#x2F;&#x2F;github.com&#x2F;npm&#x2F;npm&#x2F;issues&#x2F;17379" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;npm&#x2F;npm&#x2F;issues&#x2F;17379</a>)<p>* npm 5.0.0—5.4.1 edits package-lock.json unexpectedly (<a href="https:&#x2F;&#x2F;github.com&#x2F;npm&#x2F;npm&#x2F;issues&#x2F;17979" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;npm&#x2F;npm&#x2F;issues&#x2F;17979</a>)<p>* npm 5.0.0—5.4.? doesn&#x27;t honor incompatible version differences in package.json compared to package-lock.json (<a href="https:&#x2F;&#x2F;github.com&#x2F;npm&#x2F;npm&#x2F;issues&#x2F;16866" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;npm&#x2F;npm&#x2F;issues&#x2F;16866</a>)<p>* Take a look at the issues labeled as [big-bug], and how long they&#x27;ve languished: <a href="https:&#x2F;&#x2F;github.com&#x2F;npm&#x2F;npm&#x2F;issues?q=is%3Aissue+is%3Aopen+sort%3Acomments-desc+label%3Abig-bug" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;npm&#x2F;npm&#x2F;issues?q=is%3Aissue+is%3Aopen+sor...</a><p>* and a bunch of others I can&#x27;t remember off the top of my head; especially nondeterministic behavior in the v2 and v3 era.<p>---<p>Btw, I&#x27;m not trying to tear down npm contributors here; people have put in a monumental amount of work into the project, and the node ecosystem wouldn&#x27;t be where it is without npm.

&gt; Customers of our paid services will receive additional pre-publication vulnerability disclosures, formerly the NSP’s premium tier.<p>How common is early access to vulnerabilities as a paid service? This seems to have some ethical concerns since it dramatically increases the odds of weaponization prior to public disclosure.

This seems too little too late. Yarn is fast, stable, efficient, and (most importantly) reliable in getting things done. Doubtful anyone using yarn would switch back at this point.

Integrating nsp is a very welcome move. It&#x27;s heartening to see npm taking the security issue seriously and taking steps to start addressing the problem.<p>That said, the problem remains largely cultural rather than technical. The community needs to make significant changes to how it consumes and publishes dependencies in order to reduce the attack surface. The massive, bloated dependency graphs that developers who use Node tolerate with cavalier indifference are not safe or sustainable in the long term.

Those performance improvements sound too good to be true, how does this compare to Yarn? Although these are all excellent features I am disappointed to see that there is no support for Yarn&#x27;s &quot;flat mode&quot; which installs all dependencies in node_modules (and not endlessly nesting them).

&gt;In this winter’s ecosystem survey, we learned that 97% of worldwide JavaScript developers rely on open source code in our projects.<p>What runtime do the other 3% use to evaluate their JavaScript? Are they not using npm? If so, why are they responding to a survey by npm?

I built a runtime comparison of npm and yarn a while ago. It builds the same two things every day with different configurations (cold cache, installed, package-lock file)<p>The data can be seen here: <a href="https:&#x2F;&#x2F;docs.google.com&#x2F;spreadsheets&#x2F;d&#x2F;1ZE5B4qJw1kNGMzjgslcWTuPYrpatzQJXSYMGNOhZ2ys&#x2F;edit?usp=sharing" rel="nofollow">https:&#x2F;&#x2F;docs.google.com&#x2F;spreadsheets&#x2F;d&#x2F;1ZE5B4qJw1kNGMzjgslcW...</a>

I&#x27;m very curious what will they do when Python 2 reaches EOL. Will they keep depending on deprecated software?

There is no way for npm to guarantee security, other than auditing each version from each package one by one. Then, what is secure for one user may not be secure enough for other.<p>So it is misleading to say it is secure and that security is built in.