Hacker News new | ask | show | jobs
by manigandham 2947 days ago
> 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.

2 comments

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
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.
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.
NTFS may not handle a bunch of small files well, but I'm pretty sure WSL isn't a virtuialization layer.
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"

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