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)
* npm 5.0.0—5.4.1 edits package-lock.json unexpectedly (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)
* 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...
* 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.
I'm amazed at the disparity between the number of issues marked [big-bug] (23) and the number of those that are in the big-bug-backlog milestone (4).
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.
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 ¯\_(ツ)_/¯
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.
yarn has given me peace that I did not think was possible.
npm@6 is up to 17x faster than the npm of one year ago.
There comes a point where impressive gains cross over from a brag into an admission of guilt. The long slow is a big part of why yarn exists.
The worst performance bug I ever reported on a piece of software had an O(n^5) runtime. But our n was about 5x what anyone else was doing so it went from a couple minutes to all day. Luckily they found a workaround, because that was brutal.
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.
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.
The entire history of npm screams "we're pretty much learning all of this as we go, please bear with us".
While there's nothing wrong in that (people have to learn somehow) it does make it very, very hard to put any trust in that project. Especially when said project is at the very center of an entire ecosystem, it makes it hard to trust the ecosystem as well. I'm already seeing a lot of good developers move away from node as they gain experience and realize things should be much better.
Its pretty much standard for literally any project I've seen without senior devs to see these bugs before a release.
What are you seeing them move to?
I converted a lot of developers to Clojure myself. That language is by far the most fun I've had writing software in almost two decades of experience, where the fun comes from having simple yet really powerful tools rather than easy-to-learn-but-generates-complexity ones.
Having done projects in both languages the later is definitely much simpler and this translates into less code that does more. Its then much easier to maintain and add features.
Most of the JS/TS projects I see lose iteration speed over time, while CLJ/CLJS projects I see gain iteration speed over time.
I think by "npm of one year ago" they mean npm 4, since npm 5 came out last May. If so, "up to 17x" is plausible. But even though technically true, this is a cheap marketing move, IMO. If one doesn't read carefully, it may register as "npm 6 is 17x faster than whatever came out last year, that is npm 5".
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.
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.
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?
Probably this: https://blog.npmjs.org/post/171169301000/v571
No thanks. NPM caused the usability and feature problems first and there's no reason it won't happen again if there was no competition. Yarn is still better overall and I'm much rather they stick around.
Also, I think npm released it's lockfile too quickly. It didn't work for quite a while. Maybe it does now, I don't know, because any npm projects I have I have turned off package-lock due to it not working in the past. Yarn's lockfile just works, and always has.
So I'll stick with Yarn as long as they just keep it stable the way it is.
CommonJS/SSJS/JSGI/require() on which the node.js API is based started as a cross-platform effort of those. Maybe something like it will become relevant once again with polyglot runtimes a la GraalVM.
The data can be seen here:
The general conclusion and our experience has been the opposite and one of the big reasons why yarn exists.
So it is misleading to say it is secure and that security is built in.
And probably only guarantee it for particular version.
And "guarantee" is probably too strong a word for it, unless there is a contract with some kind of liability attached.
Same for "security", from the wording of it, they promise notifying about vulnerabilities, not performing comprehensive audits.
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".