
Announcing NPM 6 - theodorejb
https://medium.com/npm-inc/announcing-npm-6-5d0b1799a905
======
nevir
npm has eroded so much of my trust that I am hesitant to switch back to it
(from yarn) any time soon.

I've tried npm out every few months (since npm 3), and have consistently run
into infuriating bugs or unexpected behaviors.

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:

* npm 5.0.0—5.7.0 didn't play nice with git-based dependencies ([https://github.com/npm/npm/issues/17379](https://github.com/npm/npm/issues/17379))

* npm 5.0.0—5.4.1 edits package-lock.json unexpectedly ([https://github.com/npm/npm/issues/17979](https://github.com/npm/npm/issues/17979))

* npm 5.0.0—5.4.? doesn't honor incompatible version differences in package.json compared to package-lock.json ([https://github.com/npm/npm/issues/16866](https://github.com/npm/npm/issues/16866))

* Take a look at the issues labeled as [big-bug], and how long they've languished: [https://github.com/npm/npm/issues?q=is%3Aissue+is%3Aopen+sor...](https://github.com/npm/npm/issues?q=is%3Aissue+is%3Aopen+sort%3Acomments-desc+label%3Abig-bug)

* and a bunch of others I can't remember off the top of my head; especially nondeterministic behavior in the v2 and v3 era.

\---

Btw, I'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't be
where it is without npm.

~~~
tuxracer
Another gem: Trying to use `npm shrinkwrap` will cause npm to enforce peer
dependencies as required instead of just a warning
[https://github.com/npm/npm/issues/12909](https://github.com/npm/npm/issues/12909)
Despite the issue being automatically closed by a bot (due to apparent lack of
interest from the npm devs) this bug is still going strong a couple years
later. Switched to yarn haven't looked back.

~~~
realusername
npm shrinkwrap never worked well for me whatever the version, I always had
some random error at the end with it. I confirm having this bug now which
makes it useless but even before it was something else. One time when it was
still working, it was even producing invalid JSON I had to edit manually (I
wonder how that's possible).

------
inlined
> Customers of our paid services will receive additional pre-publication
> vulnerability disclosures, formerly the NSP’s premium tier.

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.

~~~
Already__Taken
don't paid npm customers get to run their own instances of npm? They need some
kind of lead time purely from a technical point of view to patch.

~~~
elmigranto
I think the point was that malicious actor gets early access to "exploits" by
becoming paid customer and has a lot of time to pwn general public.

------
manigandham
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.

~~~
BinaryIdiot
Meh; unless you're doing something really complex or ran into an odd bug, npm
is fine and so is yarn. They're both fast and stable enough and they both do
_basically_ the same thing.

I don't understand the turf war; the node module ecosystem is incredibly
shitty (good luck running any modern framework without pulling in hundreds of
dependencies) and these two tools do basically the same thing. Just use
whichever one works ¯\\_(ツ)_/¯

~~~
manigandham
Meh? NPM only started to get better after yarn was released so this is over
several years of experience.

Yarn also solved major speed _and reliability_ issues. I'm not sure why that
keeps being glossed over but NPM often had problems with reproducible builds
and generally keeping things working. Just check the top comment on this page
to see the outstanding bugs.

------
segphault
Integrating nsp is a very welcome move. It's heartening to see npm taking the
security issue seriously and taking steps to start addressing the problem.

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.

~~~
Flenser
Hopefully increased awareness of insecure dependencies among users will
increase reporting of them to dependant projects, which will encourage some or
all of the following behaviours:

1) projects to keep their dependencies up-to-date

2) projects to use less dependencies

3) consuming projects to switch their dependencies to ones that do the above

4) users to switch to projects that do the above

It would be interesting to track the average number of dependencies (total
number in dependencies in the graph) over time to see how it is changing.

------
eberkund
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's "flat mode" which installs all
dependencies in node_modules (and not endlessly nesting them).

~~~
heckanoobs
The perf improvents are real, I recently updated our build tools from npm3 to
npm5 and it shaved minutes off. npm ci is a real treat as is reliable
parallelism of npm i.

IMO yarn was a protest movement when npm wasn't adding the features devs
wanted. npm5 is the direct result and yarn should pat itself on the back and
bow out to avoid fragmenting the community.

~~~
ac2u
You make it sound like yarn was some sort of community a fork to plug some
gaps.

Why should yarn bow out? Correct me if I'm wrong, but the yarn project didn't
do the following: \- put a pre-release build under a tag that looks like a
normal build without a pre suffix \- had documentation that expressed sudo as
an acceptable way to do things to end users \- then had a bug which torched
machines if they ran any npm command under sudo. (which you shouldn't do
anyway, but see point 2) \- when pushing the fix, put hashtags in the
announcements with a distinct tone of blame towards the end users.

~~~
sebazzz
> then had a bug which torched machines if they ran any npm command under
> sudo. (which you shouldn't do anyway, but see point 2)

This was the famous "rm -Rf /" bug.

> put hashtags in the announcements with a distinct tone of blame towards the
> end users.

What are you referring to?

~~~
Murrawhip
> What are you referring to?

Probably this:
[https://blog.npmjs.org/post/171169301000/v571](https://blog.npmjs.org/post/171169301000/v571)

~~~
shawndellysse
Wow, that's very immature.

------
timvdalen
>In this winter’s ecosystem survey, we learned that 97% of worldwide
JavaScript developers rely on open source code in our projects.

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?

~~~
boffinism
I am very confident that >3% of respondents did not understand the question.

~~~
ulucs
Yeah, that’s lower than the Lizardman’s Constant*

* [http://slatestarcodex.com/2013/04/12/noisy-poll-results-and-...](http://slatestarcodex.com/2013/04/12/noisy-poll-results-and-reptilian-muslim-climatologists-from-mars/)

~~~
z3t4
I was doing some statistics on a gaming site, and thought the average age of
the users where surprisingly high, but not so much off I suspected a bug. I
did investigate anyway and it turned out some users put 9999999 as their age,
skewing the average. There's always noise, but I'm against filtering it out,
because often it's in the outliers where the interesting stuff reside, and
when it comes to software there's usually where the bugs hide. As for the
average age I did the avg on those with age between 0 and 100, as I also found
out it was possible to enter a negative age.

------
Thomaschaaf
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)

The data can be seen here:
[https://docs.google.com/spreadsheets/d/1ZE5B4qJw1kNGMzjgslcW...](https://docs.google.com/spreadsheets/d/1ZE5B4qJw1kNGMzjgslcWTuPYrpatzQJXSYMGNOhZ2ys/edit?usp=sharing)

~~~
AhtiK
Am I reading something wrong or is the comparison really indicating that yarn
is several times slower than npm?

The general conclusion and our experience has been the opposite and one of the
big reasons why yarn exists.

------
strkek
I'm very curious what will they do when Python 2 reaches EOL. Will they keep
depending on deprecated software?

------
partycoder
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.

So it is misleading to say it is secure and that security is built in.

~~~
elmigranto
> So it is misleading to say it is secure and that security is built in.

Well, it is a PR blogpost with literally that goal of wording most basic and
boring things in a way that sounds maximally sensational and groundbreaking
without becoming a lie.

Example: see how they comment on performance improvement. Instead of "compared
to previous major relase, npm 5" it says "compared to 1 year ago".

~~~
partycoder
Yeah, hopefully now they don't have a progress bar that consumes most of the
running time :)

