5 ms·

Yesterday a friend of mine told me about how they got a Node.js application from a vendor that was about 3 MiB, and after running npm install, it was over 1 GiB

Yesterday a friend of mine told me about how they got a Node.js application from a vendor that was about 3 MiB, and after running npm install, it was over 1 GiB. I half-jokingly said that Node apps are the new ZIP bombs.

hn23 7y ago
good luck to your friend with repeatable installations :P
- JustSomeNobody 7y ago
  If you need repeatable installations, wouldn't node be the wrong tool? I mean, you'd have to freeze everything yourself and then those libraries become _your_ problem. Ugh. That's a hell nobody wants.
  - quickthrower2 7y ago
    You’d just have a local cache, you can pull updates from authors if needed.
  - chrisbroadfoot 7y ago
    To be pedantic, it's "wouldn't npm be the wrong tool" (it isn't, necessarily, I believe lockfiles provide you with reproducible builds) Vendoring/copying them is another way to achieve this (and means you don't need to depend on npm or its lockfiles). Regardless, those libraries are your problem whether you vendor/copy them or not. Read more: https://research.swtch.com/deps https://research.swtch.com/deps
- news_hacker 7y ago
  "If you wish to make apple pie from scratch, you must first create the universe" - Carl Sagan the npm ecosystem takes this quite literally, for better or worse.
  - stcredzero 7y ago
    I'll credit npm with this, truly, when there's a package for each one of the Peano postulates. (As an actual functional dependency.)
xienze 7y ago
Isn’t that because every Node dependency stores its own dependencies within itself? So you could literally end up with multiple copies of the exact same version of the same library. I’ve never understood why they didn’t go with the Maven approach: all dependencies stored in a central location, separated by version.
- dhritzkiv 7y ago
  I believe the same version (within a specified semver range) are hoisted and stored in the root of ./node_modules. Differing versions are nested within the consuming packages and therefore duplicated. This can be particularly bad when a popular package has a semver major change (even if, for example, support for an outdated version of node is dropped), many libraries will lag behind in updating to the latest major version and you will have many duplicated copies of a popular package.
stcredzero 7y ago
Back in the late 90's, I got into a USENET flame war, because the smallest, easily pruned ObjectStudio executable was an entire 4MB. Not small enough. Someone around that time got Squeak Smalltalk down to around 380KB. Not small enough. Back in the late 90's, you could still meet people who would insist that even your hyper-complex business app should be written entirely in C, because anything else was sinfully slow and wasteful. Any language with a VM was automatically too slow to be useful at all.

hn23 7y ago

good luck to your friend with repeatable installations :P

JustSomeNobody 7y ago
If you need repeatable installations, wouldn't node be the wrong tool? I mean, you'd have to freeze everything yourself and then those libraries become _your_ problem. Ugh. That's a hell nobody wants.
- quickthrower2 7y ago
  You’d just have a local cache, you can pull updates from authors if needed.
- chrisbroadfoot 7y ago
  To be pedantic, it's "wouldn't npm be the wrong tool" (it isn't, necessarily, I believe lockfiles provide you with reproducible builds) Vendoring/copying them is another way to achieve this (and means you don't need to depend on npm or its lockfiles). Regardless, those libraries are your problem whether you vendor/copy them or not. Read more: https://research.swtch.com/deps https://research.swtch.com/deps
news_hacker 7y ago
"If you wish to make apple pie from scratch, you must first create the universe" - Carl Sagan the npm ecosystem takes this quite literally, for better or worse.
- stcredzero 7y ago
  I'll credit npm with this, truly, when there's a package for each one of the Peano postulates. (As an actual functional dependency.)

xienze 7y ago

Isn’t that because every Node dependency stores its own dependencies within itself? So you could literally end up with multiple copies of the exact same version of the same library. I’ve never understood why they didn’t go with the Maven approach: all dependencies stored in a central location, separated by version.

dhritzkiv 7y ago
I believe the same version (within a specified semver range) are hoisted and stored in the root of ./node_modules. Differing versions are nested within the consuming packages and therefore duplicated. This can be particularly bad when a popular package has a semver major change (even if, for example, support for an outdated version of node is dropped), many libraries will lag behind in updating to the latest major version and you will have many duplicated copies of a popular package.

stcredzero 7y ago

Back in the late 90's, I got into a USENET flame war, because the smallest, easily pruned ObjectStudio executable was an entire 4MB. Not small enough. Someone around that time got Squeak Smalltalk down to around 380KB. Not small enough. Back in the late 90's, you could still meet people who would insist that even your hyper-complex business app should be written entirely in C, because anything else was sinfully slow and wasteful. Any language with a VM was automatically too slow to be useful at all.