I wonder if they ever tried `yarn --pure-lockfile` to avoid updating the lockfile unnecessarily?<p>> We never observed install inconsistencies when using npm previously<p>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.<p>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.<p>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.
I've been enjoying pnpm as my node package manager for about a year now.<p><<a href="https://github.com/pnpm/pnpm>" rel="nofollow">https://github.com/pnpm/pnpm></a><p>It centrally downloads all of the modules and then "symlinks" them into your `node_modules` folder.<p>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.<p>Also uses shrinkwrap to handle package locking.
Just the way npm handled my bug reports made me decide never use npm cli again.<p>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 :(
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 love npm, but there's some bug that keeps looming. I have a git based dependency (basically a dependency that's attached to <a href="https://user:password@gitlab.com/xxxxxx#branch" rel="nofollow">https://user:password@gitlab.com/xxxxxx#branch</a>)<p>I don't know why, but any time I install something specific in this project:<p>npm i -D @types/tacos<p>(for example)<p>The last line of npm says this:
added 9 packages and removed 15 packages in 9.69s<p>Those 15 removed packages? Not dependency conflicts, no, thats the git dependency and all of its sub-dependencies.<p>So my workflow is now:<p>npm i --save <whatever><p>npm i
> We've published an open-source module called deyarn to help you convert your projects from Yarn to npm!<p>Would have been cool to call it "untie" or "untangle"
Still getting data loss with npm 5 and 6: <a href="https://github.com/npm/npm/issues/17927#issuecomment-393033638" rel="nofollow">https://github.com/npm/npm/issues/17927#issuecomment-3930336...</a>