To Yarn and Back to Npm Again | Hacker News Reader

To Yarn and Back to Npm Again

mixmax.com

164 pointswearhere48 comments

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).

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.

> 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.

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.

NTFS may not handle a bunch of small files well, but I'm pretty sure WSL isn't a virtuialization layer.

You're right (I didn't realize this): https://docs.microsoft.com/en-us/windows/wsl/faq#why-would-i...

It's pretty neat (I use it every day).

It closes the gap on OSX for "*nix experience on a computer that can run Photoshop and Excel"

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.

FWIW, it's fast here using Windows and powershell.

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.)

Yeah you're misreading my issue

I've been enjoying pnpm as my node package manager for about a year now.

<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

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/

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

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.

That's why we love the JavaScript ecosystem so much: you have always got something to do!

Shhhh... mutually-reinforced job security from unnecessary development churn and endless novelty.

I wonder when people will catch on.

Exactly.

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 :(

Try running a repo for free : )

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

Free open source does not mean "not for profit".

This is actually an important thing.

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.

What exactly is your problem with npm and npm.inc and what is your suggestion to fix it?

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.

> Old version just worked and got out the way.

Just when I thought I had heard every opinion on npm, I find someone with the opinion "It always worked fine."

Yarn also has a useful feature `workspaces`. With npm have to use lerna for it

This is a massive deal for monorepos. A lerna bootstrap with yarn as the package manager takes a few minutes from scratch, with npm it takes hours.

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

I love npm, but there's some bug that keeps looming. I have a git based dependency (basically a dependency that's attached to https://user:password@gitlab.com/xxxxxx#branch)

I don't know why, but any time I install something specific in this project:

npm i -D @types/tacos

(for example)

The last line of npm says this: added 9 packages and removed 15 packages in 9.69s

Those 15 removed packages? Not dependency conflicts, no, thats the git dependency and all of its sub-dependencies.

So my workflow is now:

npm i --save <whatever>

npm i

npm fixed a lot of the git dependency issues with 5.7.1. Have you tried updating?

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.

[0] : https://github.com/npm/npm/issues/17379

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.

Excellent news. Is this fix likely to fix prune by chance as well?

(That's been bloating my Electron packages for a bit in that I haven't been able to trust prune --dev not to prune dependencies of a git package.)

In any other tech company, the employee would get booted asap for sharing toxic, hateful stuff.

> We've published an open-source module called deyarn to help you convert your projects from Yarn to npm!

Would have been cool to call it "untie" or "untangle"

I've used synp. It works both ways

npm 6 still has weird caching bugs from previous versions when working with git dependencies. I'll be sticking with yarn until that gets fixed.

Still getting data loss with npm 5 and 6: https://github.com/npm/npm/issues/17927#issuecomment-3930336...

can somebody tell me why the thumbnail of this page shows report data with probably private email data? (see og:image meta tag on that page)

This sounded interesting, but turns out it's just the screenshot from their homepage [0]

[0] https://mixmax.com/

Reply on news.ycombinator.com