Live data from Hacker News

To Yarn and Back to Npm Again

mixmax.com

21–30 of 54 posts

Re: To Yarn and Back to Npm Again

#21
post #19

I've been enjoying pnpm as my node package manager for about a year now. " rel="nofollow">https://github.com/pnpm/pnpm> It centrally downloads all of the modules and then "symlinks" them into your `node_modules` folder. This is nice because one, it uses less disk space, two, if you've already downloaded a package at a particular version it links it out of the local repo. Also uses shrinkwrap to handle package locking…

Yes, pnpm is awesome. Only occasional issue was for me, that it didn't installed peerDependencies by default. Also not sure if it's gonna work in environments like react-native (never tested).

Re: To Yarn and Back to Npm Again

#22
post #19

I've been enjoying pnpm as my node package manager for about a year now. " rel="nofollow">https://github.com/pnpm/pnpm> It centrally downloads all of the modules and then "symlinks" them into your `node_modules` folder. This is nice because one, it uses less disk space, two, if you've already downloaded a package at a particular version it links it out of the local repo. Also uses shrinkwrap to handle package locking…

I agree, pnpm is excellent. The node_modules directory can easily take up hundreds of megabytes, and the storage space savings that pnpm provides are really convenient when you write a lot of small projects with similar sets of dependencies. I did a comprehensive benchmarking comparison on npm, pnpm, and yarn a while back, and pnpm was the clear winner for my needs [1]. Those benchmarks are admittedly outdated now because, as this submission points out, npm 6 introduced significant improvements over npm 5. Despite that, pnpm is still an underappreciated contender in the space.

- [1] https://github.com/pnpm/pnpm

- [2] https://intoli.com/blog/node-package-manager-benchmarks/

Re: To Yarn and Back to Npm Again

#23

I wonder if they ever tried `yarn --pure-lockfile` to avoid updating the lockfile unnecessarily? > We never observed install inconsistencies when using npm previously Interesting, since NPM has had issues being deterministic since package-lock came to be, and this was one of the main reasons yarn was created. The fact that yarn has a healthy community, actually accepts contributions, and encourages public discussion…

A small detail from the error outputs that might tell a lot:

NPM error: ~probably not our fault, there might be additional output above

Yarn error: ~an error has occured, here's what you'd do if you think it is a bug

NPM is probably correct most of the time but the difference in attitude felt striking to me.

Re: To Yarn and Back to Npm Again

#24
post #9

We're using a boilerplate project from a year ago with Yarn/React and it's still behaving the same way. Of course we have some deprecation warnings, but is it really so bad to have this "If it's not broke, don't fix it" mentality?

That doesn't gain you as many stars on GitHub, conference talks, TechCrunch articles and HN threads.

aka the social media for everyone who likes to hate on mainstream social media

Re: To Yarn and Back to Npm Again

#25
post #14

> Yarn often produces yarn.lock files that are invalid when you run add, remove, or update. This has never happened to us with heavy daily usage. It's one of the things that remains reliable about Yarn. Would appreciate more details on what exactly happened.

Here's an issue I've experienced with using upgrade: https://github.com/yarnpkg/yarn/issues/5749

> and I noticed that certain packages were completely missing from the node_modules folder, yet are listed in yarn.lock

Sounds like what I'd expect from running yarn clean...

(If anyone isn't aware: that command doesn't clean target folders but rather goes crazy inside node_modules.)

Re: To Yarn and Back to Npm Again

#26
post #11

Earlier quoted context omitted.

Our experience has been yarn is fast and reliable.

Hmm, `yarn add` reliably takes a few years in my environment (WSL). Maybe the environment is the problem, though.

The windows subsystem for linux? It's dealing with lots of tiny files going through a virtualization layer, you might want to just use the Windows native version of Yarn which is very fast.

Re: To Yarn and Back to Npm Again

#28
post #19

I've been enjoying pnpm as my node package manager for about a year now. " rel="nofollow">https://github.com/pnpm/pnpm> It centrally downloads all of the modules and then "symlinks" them into your `node_modules` folder. This is nice because one, it uses less disk space, two, if you've already downloaded a package at a particular version it links it out of the local repo. Also uses shrinkwrap to handle package locking…

I always wondered why npm didn't use symlinks more... (at all?)

Re: To Yarn and Back to Npm Again

#29
post #19

I've been enjoying pnpm as my node package manager for about a year now. " rel="nofollow">https://github.com/pnpm/pnpm> It centrally downloads all of the modules and then "symlinks" them into your `node_modules` folder. This is nice because one, it uses less disk space, two, if you've already downloaded a package at a particular version it links it out of the local repo. Also uses shrinkwrap to handle package locking…

Yes, pnpm is awesome. Only occasional issue was for me, that it didn't installed peerDependencies by default. Also not sure if it's gonna work in environments like react-native (never tested).

Neither do yarn or npm AFAIK

Re: To Yarn and Back to Npm Again

#30
post #19

I've been enjoying pnpm as my node package manager for about a year now. " rel="nofollow">https://github.com/pnpm/pnpm> It centrally downloads all of the modules and then "symlinks" them into your `node_modules` folder. This is nice because one, it uses less disk space, two, if you've already downloaded a package at a particular version it links it out of the local repo. Also uses shrinkwrap to handle package locking…

Been using pnpm for about 3 months solid now and I'm a huge fan. Most packages rely on node's built-in resolve system and have no problem with pnpm's symlinks. For packages like Jest and Webpack that have some custom resolve logic, I just use the `--shamefully-flatten=true` option and everything is perfect.

Saved me over 6GB on my file system across several projects. Big thumbs up from me.

Post reply on HN