Live data from Hacker News

Disabling npm's progress bar yields a 2x npm install speed improvement

twitter.com

31–40 of 187 posts

Re: Disabling npm's progress bar yields a 2x npm install speed improvement

#31
post #21

Upon first seeing npm 3.x I immediately added `--progress false --color false` to my npm installs and never looked back. Color and terminal graphics are the work of the devil.

> Color and terminal graphics are the work of the devil. Or you know, it's 2016, and it's npm who does it badly.

I don't even want color and terminal graphics done goodly. I code with two monochrome terminals on the screen using vim and the command line.

Re: Disabling npm's progress bar yields a 2x npm install speed improvement

#33
post #21

Earlier quoted context omitted.

> Color and terminal graphics are the work of the devil. Or you know, it's 2016, and it's npm who does it badly.

I don't even want color and terminal graphics done goodly. I code with two monochrome terminals on the screen using vim and the command line.

Not everyone is you. While I agree that flashy graphics are silly in the command line, I find color-based highlighting to be quite useful.

Re: Disabling npm's progress bar yields a 2x npm install speed improvement

#34
post #11

Earlier quoted context omitted.

Awesome tool, but wish the url was a bit easier to spell/remember!

I'm not sure "IED" is the best acronym to go for, either: https://en.wikipedia.org/wiki/Improvised_explosive_device

Didn't stop NUKE, PHP Nuke, DotNetNuke, etc.

Re: Disabling npm's progress bar yields a 2x npm install speed improvement

#36
post #14
post #6

The funky progress bar is about the coolest thing with npm. They could let it take a minute if they wanted too and i would keep watching it with amazement.

npm 2.x user here. Does anybody want to share a video of the 3.x progress bar? (Easy with QuickTime or CloudApp, btw)

https://asciinema.org/a/9gt0i1kxbto41gj4796tjkdnt

Re: Disabling npm's progress bar yields a 2x npm install speed improvement

#37
post #12
post #9

Progress bar or not, npm has gotten extremely slow with v3, to the extent that someone is working on a performance-centered alternative called ied: http://gugel.io/ied/ installs are literally the #1 thing npm needs to do well, and I really hope we see some improvement soon.

Even more important, npm doesn't reliably reproduce builds. Different runs of the same shrinkwrapped build could either fail or succeed -- which is odd given that builds should be deterministic. Additionally, shrinkwrap is also broken in the same way. This is the first time I've heard of ied, a little competition could go a long way!

Could you expand on that? What causes it to be nondeterministic? I haven't had that experience but it's the second time I've read someone reference this behavior

Re: Disabling npm's progress bar yields a 2x npm install speed improvement

#38
post #6

The funky progress bar is about the coolest thing with npm. They could let it take a minute if they wanted too and i would keep watching it with amazement.

you mean the progress bar that takes up way too much screen real estate to the extent that it completely cuts off any useful information from the install process?

Yes, that one. I agree with you, by the way. I don't have a terminal in front of me, but the progress bar seems to leave something like 10 characters of less of rapidly-changing status updates in exchange for the vast majority of horizontal real estate. I bet if they had split the bar onto a separate line from the status, it would run faster

Re: Disabling npm's progress bar yields a 2x npm install speed improvement

#39
post #36
post #14

Earlier quoted context omitted.

npm 2.x user here. Does anybody want to share a video of the 3.x progress bar? (Easy with QuickTime or CloudApp, btw)

https://asciinema.org/a/9gt0i1kxbto41gj4796tjkdnt

Holy crap that was fast.

Re: Disabling npm's progress bar yields a 2x npm install speed improvement

#40
post #37
post #12

Earlier quoted context omitted.

Even more important, npm doesn't reliably reproduce builds. Different runs of the same shrinkwrapped build could either fail or succeed -- which is odd given that builds should be deterministic. Additionally, shrinkwrap is also broken in the same way. This is the first time I've heard of ied, a little competition could go a long way!

Could you expand on that? What causes it to be nondeterministic? I haven't had that experience but it's the second time I've read someone reference this behavior

I have a project that's shrinkwrapped. I check out a new copy of the project and run `npm install`. My co-worker does the exact same thing, his fails, yet mine successfully builds. An install of a shrink-wrapped should be deterinistic, i.e. either succeed or fail, but not both.
Post reply on HN