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 is a big pro for me (colored by personal experience).
> 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.
You need to add an exclusion or two to Windows Defender. The yarn folder in %APPDATA% is one (if you're running yarn locally, same deal for npm), and the path to where you keep your repos is the other (which is a lot easier if that doesn't exist entirely inside your WSL filesystem).
The reason it's so slow is because the virus scanner is running on the insane amount of tiny files a typical JS app will have. Used to take me 30 minutes each time until I did that; it was still slower than Linux/Mac but it was coffee-break slow, not three-course meal slow.
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.
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.
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.
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).
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.
I once brought up what you said to an acquaintance and, wow, the way the color drained from his face, the way his voice hardened and lowered in tone, as he said "That's just a bunch of bullshit.". Later that month, he would go to work for IBM as a junior-level front-end engineer.
As always, it's probably better to be quiet and let the insecure live in their own little worlds.
Just the way npm handled my bug reports made me decide never use npm cli again.
The registry is something everyone has to use because npm has a monopoly. It's not open source and is making money for a for profit company. I'm very disappointed to see Node.js is still shipping this anti-foss OSS with its executables :(
As you might infer from my comments I'm not the biggest fanboy but criticising them over running a freely available repo that the community has used for years feels a little bit wrong
npm CLI is run by Npm Inc. Npm makes money by maintaining the CLI as their primary selling point. for profit. Yarn is also have many paid engineers from Facebook and Google contributing to it as their day job.
These things are not real free open source software by any means
Huge parts of the largest open source projects comes from "paid engineers from Facebook and Google contributing to it as their day job" or even from IBM, Microsoft or Oracle employees.
What matters is that it is released as open source so we can maintain it or pay someone else to do it.
The special thing about npm is they also run the package repo but even there I'd say they played nicely by allowing free use and not discouraging alternative clients.
I'm not sure I like the new npm. It seems faster but it's annoying to use it with how often it prompts you to update it and all the verbosity, annoying messages about peer dependencies, and now audits that you can't really do anything about. There's just so much noise now. Old version just worked and got out the way.
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?
I worked with @iarna over at npm to get a very similar bug fixed - https://github.com/npm/npm/pull/20198. I'm pretty sure this is just a special case of that bug - if you're not on npm 6.1.0 it might be fixed there. Otherwise I'd encourage you to comment in on that PR / the attached issue with a flow to reproduce.
I had this issue as well. I found an outstanding issue [0] on github. Running npm install -g npm will update your npm to the absolute latest version, which resolves this erroneous removal.
> 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 is a big pro for me (colored by personal experience).