To give some perspective, I'm dealing with systems that install npm packages at scale. NPM3 has had way too many show stopping bugs for us. The delays in installation time compound when dealing with thousands of packages, pretty much causing package installation to fail ( take forever ).
Unfortunately, as detailed in a few npm3 threads, npm3 performance may forever be quite bad, due to a few ill-conceived features in npm's infancy.
Due to shrinkwraps and bundleDependencies, it's impossible for npm to know the full dependency tree until it has untarred every intermediate dependency [1]. In the future, it may be possible for a smarter server to cache this data and serve the full tree as part of the metadata, but that is a ways away.
There are some low-hanging fruit still in npm; for instance, the npm registry still doesn't gzip metadata for some unknown reason. Doing so could save as much as 80% on some larger metadata json, such as npm/npm itself [2].
v3.7.0 of npm [1] fixed the previously submitted performance problem with the progress bar [2].
Which is not to say you are incorrect (as often disabling logging to the console can speed up operations), but for the most part the bug has been fixed.
Unfortunately I've not had much luck getting pnpm or ied running on Windows due to the symlinking stuff (though the installation portion is super quick), so hopefully the speed improvements here can help lessen the blow a bit.
While progress=false does decrease install time a little, it's still very long. And the output is incredibly verbose - I'm doing something similar to the OP in automating builds of Node apps and npm is easily the biggest headache in the process.
BTW, "npm install --production" installs all dependencies but not devDependencies (which you can get by doing "npm install --save-dev <package>"). That way you can separate dev and prod dependencies within the same package.json file.
Feels a little backwards that you specify dev on module install but prod on app install. Maybe --production being the default and --dev being an option makes more sense, but that would be one hell of a breaking change.
Anyone tried ied on Windows? I wanted to give it a go but it seems like there are a number of problems with permissioning / the symlink system [1].
That led me to trying pnpm [2] which, on the plus side can install my dependencies (and fast!), but on the other hand seems to do so in a way that my grunt tasks no longer work (complaining about missing sub-dependencies).
Feels like this "do [x] while npm install is running" silly project is turning into a running gag. Why not fix the issues with NPM install that makes it extremely slow instead? Not saying that people shouldn't make things just for fun, but when you've got 10 different projects around the idea that NPM install is slow and you should do play a game or watch silly gifs while it's installing, maybe the time would have been better spend fixing the problem.
You're right, it's a joke. I was chatting to a colleague about how long his installs took to run and I thought having a game where you shoot all the packages that are installing would poke fun at the fact that you're probably installing way too many packages. I agree, fixing the problem would have been better, though probably harder and definitely less enjoyable.
I can't agree more, but honestly who's surprised here?
Since the introduction of nodejs and NPM, JavaScript developers have been on a ridiculous NIH-fuelled frenzy to recreate everything that ever existed, using as many dependencies (and sub-dependencies) as humanly possible to do so, while also actively choosing to not solve problems that they come across, and instead implementing ridiculous work arounds or replacing/rewriting entire components or apps, rather than working out they were missing a config option, etc.
I am not at all surprised that the nodejs/npm community's response to NPM being such a pig, is to put lipstick on that pig, and try to make it look prettier, while doing nothing about it shitting all over the couch and proceeding to lay in said shit.
It definitely would be better to just solve the problem. This is classic result of an OSS community responding to a problem with complaints or new, unrelated/irrelevant projects. Yet, being OSS, we have the means to fix it.
To be quite frank, I am not an expert in npm's underlying architecture. But this post has inspired me to actually do some research. The fact that there is an alternate package manager shows there is a huge problem.
I love the idea of user interfaces that provide little distractions from long-running (usually unavoidable) tasks. It's silly, but the right kind of silly.
I recently purchased a Korg Minilogue analog synthesizer. Because of the instability of analog oscillators it has to go through a tuning procedure when it's first powered on (which can take around 20sec). They included a little game of breakout to help pass the time, though :)
> I love the idea of user interfaces that provide little distractions from long-running (usually unavoidable) tasks.
Something like a java/c/etc compile on a large project is an unavoidable delay. And yet those tools don't offer to jingle some keys for you to make you feel like its quicker. They just do what they can to make the process as quick as possible.
Installation of packages that don't require compilation (e.g. decompressing files, moving them and possibly running some simple tasks) is not unavoidably slow. NPM is just a terrible package manager, and the community is in some kind of munchausen situation.
To give some perspective, I'm dealing with systems that install npm packages at scale. NPM3 has had way too many show stopping bugs for us. The delays in installation time compound when dealing with thousands of packages, pretty much causing package installation to fail ( take forever ).