Yeah, for building files in docker try using multi-stage builds. They on the "final" image you can only use prod dependencies.

So we’re using multi-stage builds (totally awesome feature!), only including production dependencies, and I’m —squash ing the final image.

The issue is that packages often balloon in size from an accidental transitive inclusion of Babel or webpack. Because JS packages depend on so much, the fanout virtually guarantees someone in your dependency tree will accidentally a dependency every now and then. It’s compounded by the fact that I have several different versions of the same package installed because folks don’t use peerDependencies when they should (and I’m afraid to pin most packages because I don’t want to introduce subtle bugs).

I’d imagine I could solve this for us if I had enough time, but startup life leaves little time for battling with the package manager. And it creeps up on you slowly.

(Also: we use next-transpire-modules @martpie, thanks for a great library)

Yeah, sounds like the kind of problems you’d hand to your devops team, but oftentimes that’s just you :D

I wonder how much “build maintenance” is/will become a factor in choosing between ecosystems.

All I’m hearing is that now and then a teammate makes a mistake and installs a dev dependency as a production dependency. How is this NPM’s fault?

This is not what I said.

100-150mb of just a JavaScript code doesn't look that great either.

I think the problem is that you normally use 5% of the functions from your deps but still have to pull it all in.

Minimizing dependencies and writing as much as possible on your own would probably cut a 500 MB nodejs project to 5 MB in plain JS.

Note: Not a node dev but share the grief...