Npm v5.1.0 Released | Hacker News Reader

Npm v5.1.0 Released

github.com

22 pointsankit8414 comments

Is there any reason to use Yarn now that NPM has comparable speed and lockfiles?

Anecdotally, yarn is significantly faster. Makes a difference if you have lots of dependencies.

I used npm a lot and had sporatic unexplainable errors. I haven't used npm 5 to say if it's been fixed, but that turned me off.

I've had this issue too with npm on my build server - sometimes things just fail, maybe it's flaky network, maybe it's some package update that didn't quite go as planned, but yarn seems to solve it and works a lot faster to boot, so I'll be sticking with it for now.

npm5 and 5.1 has improved performance significantly so that it's comparable with yarn.

We switched to yarn in the past and switch back to NPM a couple of weeks back, after npm 5 delivered usable performance.

A problem with yarn was, that it has trouble upgrading all dependencies: https://github.com/yarnpkg/yarn/issues/3492

I haven't tried yarn but for those who did, what made you make the change?

Getting my node_modules corrupted several times (packages in package.json "randomly" going missing after installing new ones) requiring nuking node_modules and doing a fresh npm install.

yarn has been a breeze to use so far, I'm loving the quick installs. Only nitpick is that I have to be inside of the working directory of the package.json when adding a new package, because yarn for some reason does not travel up the hierarchy and installs it in the same directory as the first encountered package.json, like npm does.

I keep getting bitten by this. It's really annoying.

The killer feature for us was a more maintainable lock file. Back when we switched, it was way more readable than the npm-shrinkwrap.json and it is easier to fix merge conflicts in the yarn.lock.

And if you are wondering: Why a lockfile? It has also been a game changer, everyone in my team has the same dependencies installs, dependencies do not suddenly break. (Anecdote: Before the switch some dependency of an dependency of an dependency overwrote some Array function, and broke our whole product. I was on vacation and had to fix this remotely, because it was kind of hard to debug).

The only obstacles we ran into: 1) private registries did not work, but this has been fixed 2) yarn upgrade command behavior is sometimes funny, but this is going to be fixed soon:

- https://github.com/yarnpkg/yarn/issues/3603

- https://github.com/yarnpkg/rfcs/blob/master/text/0000-upgrad...

1. A lock file that works well. My team spent countless hours dealing with strange npm shrinkwrap issues beforehand. The fact that it uses a lock file by default is also nice, since people don't have to remember to update it after adding or removing a package.

2. Deterministic installs (running install with the same lockfile will result in the exact same node_modules). With npm, we ran into issues that would somehow be fixed after deleting the node_modules directory and reinstalling everything. That worked far too often.

3. The offline mirror. This gave us a reasonable method for checking in our packages to our Git repo, meaning we could build our site without an internet connection.

It basically fixed all of our issues with npm, saving us hours upon hours of time.

I've switched from npm to yarn[1] a long time ago. never going back.

[1] https://yarnpkg.com

This is a good time to look at npm again and compare. I will not say one is better than the other, but npm v5 has a lot of improvements and addresses most of the reasons why yarn existed to begin with.

twice as fast ... in some benchmarks

twice as fast, if you are on nodejs 8, however on node lts you can't update/install new packages! (so basically it's even faster since no install is ridicoulus fast)

Reply on news.ycombinator.com