undefined | Better HN

0 pointsjdavis70310y ago0 comments

What's the point of shrinkwrap if you're commiting node_modules? And also why not use a package manager like RPM, Debian, etc so you don't bloat your Git history? (Genuine questions, I know many advocate what you're saying).

0 comments

chromakode10y ago

Vendoring by storing node_modules works great. It's not necessary to shrinkwrap in that case -- all the same data is derived from the node_modules directory tree. For production, I often use a separate git repo for storing node_modules, referenced as a submodule of the code repo. This has two advantages:

* You retain history for your full dependency tree separately from your codebase.

* Every commit of your code repo exactly specifies the contents of its dependency tree, since the submodule references your deps repo by commit hash.

acemarke10y ago

Re-re-posting a comment I've made in a few threads now, because I feel this needs to get more awareness:

I'm still learning and prototyping my first JS/NPM/React project, but 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.

j / k navigate · click thread line to collapse