Hacker News Reader

Comment by dikaiosune | Hacker News Reader

I'm definitely curious to see if the update to npm 5.5.1 resolves most of the issues people have seen on the 5.x releases. Otherwise having an LTS release with a rough release of npm might be pretty painful for a lot of the ecosystem.

View on HN

Yarn [0] might be a great alternative for those who have been bitten in the proverbial ass by npm a bit too many times.

[0] https://yarnpkg.com/lang/en/

I've recommended yarn for projects of mine that were broken by npm5, but it has some of its own issues. It's also not bundled by default which is really important for JavaScript tools that are used by beginners.

Our deployment setups explicitly roll back to npm 4. every version of npm5 has had problems with some step (currently fighting issues with react-native), including the latest 5.5.1 :(

Another option is pnpm(https://pnpm.js.org), a lesser known but much faster alternative.

yarn has resolved most of the issues already :)

In my experience that’s simply not true.

We’ve seen more issues with Yarn in CI & prod than with npm 5.x

Both are great projects but npm is significantly more mature.

I guess it just depends on what you are doing. With npm 5.x installed packages started disappearing at random for me. Switched to yarn and no problems since.

I have never seen that (or even heard of it). How bizarre.

I've had it happen to me before. It's weird and annoying, and you basically have to nuke node_modules and sometimes package-lock.json, and then re-install everything to fix. That usually works.

https://github.com/npm/npm/issues/17929 and linked bugs.

Just out of curiosity, having never encountered any issues myself - what sort of issues have you run into with Yarn in CI/prod ?

Reliability, mostly. Also some strange cases where it would just plain fail (but then work if re-run).

We do use private scoped packages a lot so that might have some bearing on it.

I use private scoped packages (and monorepos, and yarn) too, and have generally had a fine time with it.

Would be interested in specifics of your reliability and failure problems too.

We just started using yarn workspaces and are running into weird issues where our private scoped packages don't always get installed on `yarn install`.

Yarn claims to be deterministic but I still need to `rm -rf node_modules` regularly when I run into weird build errors. It's quite strange.

Well... I don’t use it anymore because frankly, there’s no need.

Is there any chance that you are using npm to install yarn?

I had mistakenly setup our CI to do that at one point and it caused a lot of hard to debug problems.

I was not, but even if I was that speaks to Yarn’s quality imo because they recommend that as an option.

We finally got NPM out of the loop for production deploys and it's been glorious. We ship down a tarball of the repo after an npm install and include a node interpreter.

Ah well, that’s a whole different kind of system. Similar to doing a docker image ship.

Still have to do the install on a deploy server.

seems like a perfect use case for Docker.

I whole heartedly agree. Would you tell that to my boss? :D

Agreed. I tried to switch to yarn a couple times now and it simply wasn't reliable (though the last attempt was a few months ago)

Yea I'm big fan of it. Strange things used to happen with npm, dependencies would break, installs would fail etc... Maybe something to do with our build config, but since moving to yarn, no problems. We don't ever think about packages breaking or anything now (which is how it should be).

I’ve seen zero issue with npm locally or in production (have more issues with Webpack tbh)

What kind of problems?

I've had major trouble with the fact that the new package-lock.json doesn't sufficiently lock versions. In one working copy you can run "nom install" and everything works with no files or package-lock being changed. Yet, in another clean checkout, "npm install" brings in a different set of dependency versions despite having a -lock file, and things start to break. Yarn's yarn.lock seems to get this right.

any chance that you did `npm install --production` maybe? i think the lock file might be different for that case.

There are a bunch of linked issues at https://github.com/nodejs/node/issues/13815 and https://github.com/npm/npm/issues/16991, such as https://github.com/facebookincubator/create-react-app/issues....

How are we nearly a decade into the life of NodeJS and still suffering from problems with its package manager, which itself is up to version 5.x?

Because npm 5 was a pretty big update that fundamentally changed how a lot of npm portions work, in order to close the gap between it and Yarn, a competing package manager. The 5.0 release was super rushed IMO (I personally hit several bugs), but if you stuck to node LTS you skipped over most of the v5 breakage (now it works 99.99% of the time again, and when it doesn't work deleting node_modules usually does the trick)

npm v5 is still deleting private packages - the issue has been open, accepted and replicable since npm v5 was released - see https://github.com/npm/npm/issues/17929 nad various related issued linked from that page. This sucks if you use a monorepo.

yarn workspaces works a treat though.

package management is a harder problem than most people seem to want to admit. I've run into tons of issues with every package management system you can think of: rpm does some extremely dodgy caching stuff at times, navigating maven dependency trees to identify the offending version of slf4j that is harshing the vibe, etc.

I can't think of a single package management system that works well and people seem to love.

Nuget. Can't remember last time i had issues.

Cargo?

> which itself is up to version 5.x

Major version numbers in Javascript are defined using SEMVER. What this means is that a major version only implies that a breaking change was included (e.g. the API contract is different). It doesn't really have anything to do with a classic pattern where V2 is seen as the second phase, and V5 is seen as the fifth phase, etc, of a project.

A breaking change should not be made lighthearted. It can cause a lot of inconvenience for your userbase.

Reply on news.ycombinator.com