Show HN: Turn NPM installs into a Space Invaders style game in your terminal | Hacker News Reader

Show HN: Turn NPM installs into a Space Invaders style game in your terminal

npmjs.com

105 pointsmassivedragon34 comments

If you are tired of waiting for NPM, I'd suggest checking out the `ied` alternative: https://github.com/alexanderGugel/ied

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

Try to set

    npm set progress=false

it speeds up installation time. I am also approaching an alternative solution, to put dev deps in another package.json, then do something like

   npm install src/dev

where src/dev is a folder that contains a package.json with dev deps only when you are developing.

isn't that what devDependencies is for?

"npm install" installs devDependencies too. You can do "npm install --production" to skip them.

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.

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.

[1] https://github.com/npm/npm/releases/tag/v3.7.0

[2] https://twitter.com/gavinjoyce/status/691773956144119808

It has not been fixed: I did a series of PRs on this [1] and the most impactful of them was not merged, although a few smaller ones were.

@iarna got to the root cause (instead of simply throttling it as I had been doing) but it has not yet been merged into npmlog. [2]

1. https://github.com/npm/npm/issues/11283#issuecomment-1757522...

2. https://github.com/npm/npmlog/pull/28

Fair enough, I'm not up with npm's development on a PR level, so I was just going by this line in the changelog:

"This has been patched to eliminate that churn, and our testing shows the progress bar as being eliminated as a source of slow down."

Apologies for being misleading.

Just to update you - looks like this has finally been released:

https://github.com/npm/npm/releases/tag/v3.8.3

Great, thanks! I'll check it out.

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.

As an aside, why does npm check-in the node_modules folder into their repo?

I was under the impression this was generally considered bad practice, so it seemed weird seeing it done by the package manager itself :)

ied is great, and getting better.

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

1. https://github.com/npm/npm/issues/8826#issuecomment-15511591...

2. https://github.com/npm/npm-registry-couchapp/issues/224

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

[1] https://github.com/alexanderGugel/ied/issues/35

[2] https://github.com/rstacruz/pnpm

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 can't fix fundamentally flawed systems.

In what way is it fundamentally flawed?

NIH'ed package management such that we now have yet another broken scheme for managing packages ..

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.

This is awesome. Thanks!

I think it's an effective satire on the existing implementations of the gag.

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

Loading screen minigames were under a Namco patent until last year: http://gamasutra.com/blogs/DavidHoppe/20150109/233806/2015_T...

I wonder if the patent would have covered this since it's not "loading", it's installing.

Steam should bring back mini games between friends.

It’s Invade-a-Load all over again!

https://en.wikipedia.org/wiki/Invade-a-Load

Oh that's fantastic! I'm afraid I'm probably too young to have known about that, but it's obvious I was wrong when I thought I was being original!

Feature request: Only install dependencies once you've blasted them.

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

https://www.youtube.com/watch?v=LDWv-KgzMXM

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

> Uh oh. Looks like you failed to install any packages.

> Have you tried just mashing the spacebar?

Gave me a good chuckle XD

Nifty.

This cool "arms race" cannot go unanswered, it demands Ruby gem-install-pac-man. ;)

     ᗧ ････️････       and: ᗣᗢᗤ┏┗┓┛┣┫┻╋┳┃━

Also: Alien monster https://duckduckgo.com/?q=U%2B1F47E

Oh man I needed this yesterday. Was doing some livecoding, stupidly decided to run npm install, and there was dead air for waaaaaay too long.

This would've been perfect.

As an old boss of mine put it once: "What this means to users is that there are no bugs in the program."

Reply on news.ycombinator.com