3 ms·

Well... I spent the last hour hiding under my desk, curled up in the fetal position, shaking and crying uncontrollably. Left-pad is back in NPM, but that reall

Well... I spent the last hour hiding under my desk, curled up in the fetal position, shaking and crying uncontrollably. Left-pad is back in NPM, but that really doesn't the address the underlying issues. I don't know what we're going to do really. Hoping a new set of "best practices" for dependency management reveal themselves in the next few days. Checking our node_modules folder into source control (and avoiding ever 'npm install'ing again), seems like a bad idea. NPM "shrinkwrap" seems like it could work, but not if the modules disappear from NPM. Creating our own NPM mirror and disabling "unpublish" seems plausible, but is it worth the effort? Idk... I'm considering assembling our node_modules folder from github commits rather than npm package names, but that's only a solution if all of our dependencies are doing the same thing (otherwise we're still tied to NPM in some way and vulnerable to packages being unpublished). And of course things can be taken down from Github just the same...but at least Github is namespaced to the username. I think the only "good" solution is to disable unpublishing from NPM...but that's completely out of my control. Back to the fetal position...

acemarke 11y ago
I'm still learning and prototyping my first JS/NPM/React project, but https://github.com/JamieMason/shrinkpack https://github.com/JamieMason/shrinkpack seems to me like it solves _most_ of the issues involved here. It pulls down all the tarballs, and updates the npm-shrinkwrap.json to point to those instead. That way you check in a much smaller "node_shrinkwrap" folder of a few hundred tarballs and 15-20MB, rather than a node_modules folder of 30K files and 150MB and a bunch of platform-specific build outputs. Still doesn't solve the issue of installing new/updated dependencies that might actually require pulling in something that vanished, but at least once you've done an install and run "shrinkpack", you've got everything you need to rebuild right there.
cballard 11y ago
Does NPM offer a way to check in your resolved dependencies? While it would brick updates to dependencies, new clones and builds would work fine.
swanson 11y ago
> Checking our node_modules folder into source control (and avoiding ever 'npm install'ing again), seems like a bad idea. Why? Vendoring dependencies is a "thing" people do.
cjbprime 11y ago
FWIW I've been pointed to https://blog.dylants.com/2014/05/10/creating-a-private-npm-registry-with-sinopia/ https://blog.dylants.com/2014/05/10/creating-a-private-npm-r...

acemarke 11y ago

I'm still learning and prototyping my first JS/NPM/React project, but https://github.com/JamieMason/shrinkpack https://github.com/JamieMason/shrinkpack seems to me like it solves _most_ of the issues involved here. It pulls down all the tarballs, and updates the npm-shrinkwrap.json to point to those instead. That way you check in a much smaller "node_shrinkwrap" folder of a few hundred tarballs and 15-20MB, rather than a node_modules folder of 30K files and 150MB and a bunch of platform-specific build outputs. Still doesn't solve the issue of installing new/updated dependencies that might actually require pulling in something that vanished, but at least once you've done an install and run "shrinkpack", you've got everything you need to rebuild right there.

cballard 11y ago

Does NPM offer a way to check in your resolved dependencies? While it would brick updates to dependencies, new clones and builds would work fine.

swanson 11y ago

> Checking our node_modules folder into source control (and avoiding ever 'npm install'ing again), seems like a bad idea. Why? Vendoring dependencies is a "thing" people do.

cjbprime 11y ago

FWIW I've been pointed to https://blog.dylants.com/2014/05/10/creating-a-private-npm-registry-with-sinopia/ https://blog.dylants.com/2014/05/10/creating-a-private-npm-r...