Hacker News Reader

Comment by falcolas | Hacker News Reader

It bothers me that I have to agree with this. I watched an NPM install once, and noticed that one particular library was downloaded and compiled somewhere around 40 times (and each compiled version was different).

Think about that for a moment: one library, 40 versions downloaded and compiled to fill NPM dependencies. What if there was a vulnerability in a version of that library - how do I audit that? Can I even fix it myself without hosting my own NPM registry? Bandwidth? Computation costs (a thing again, with cloud computing)? Disk space costs?

It makes me glad we just use Docker; so I don't have to try and make sense of the NPM madness from day-to-day. Just Docker's own brand of madness.

View on HN

Personal experience: NPM can be mind-bogglingly slow in Windows. In my previous day-job, an NPM install on Windows 7 could take hours, for some reason. That's NPM 3 with about 20 dependencies on a small project.

NPM on Windows also had other problems such as Python path is wrong or C++ compiler is missing.

Then we switched to Yarn. Uncached install took about 2-3 minutes, and cached install would finish in seconds.

Recently, NPM 5 has been released, and it's been competing well against Yarn.

Still a bigger fan of Yarn here. My personal tests have Yarn running a bit faster still, but I also like that Yarn's command syntax is easier. NPM seems content with making a million aliases of everything and it's annoying. I think they even added 'add' from Yarn.

Also, Yarn's run command can be used to run locally installed NPM binaries, not just NPM scripts. i.e., you can do `yarn run -- webpack` and it will run the local copy of Webpack. This is handy imo, and as far as I know NPM doesn't do it.

I didn't know that, thanks for pointing out.

I like Yarn run, because if I'm running a lint or tests, it errors out with error messages related to the specific process.

If you run via npm run, it would throw lot of extra error messages, making excuses that it wasn't NPM's fault the command exited with a non-zero status etc.; and hiding the relevant error messages.

And as always, you can just run a script as yarn script, instead of yarn run script; like yarn lint:src, instead of yarn run lint:src.

NPM does it only for a few common ones.

Also, Yarn run picks up right node version from .nvmrc - you don't have to run an nvm use and switch to it.

FWIW npm 5 comes with npx [0] which basically does similar things. If you run npx webpack it would use the local copy of webpack or even install one run it and discard it.

[0] https://www.npmjs.com/package/npx

That's not the same thing. Npx is for running commands you install from npm, and yarn [command] allows you to run scripts defined in your package.json file.

npm always did this. The OC said that he likes that yarn can also run local binaries that are not a npm script.

Reply on news.ycombinator.com