> just zipped the whole folder node_modules and all and shipped that
I mean, in a sense, something similar is what you should do if you're aiming for maximum reproducibility, of course, excluding the things that you don't need.
For a comparison, if you wanted to build a Docker container, it's going to include the node_modules folder in it, instead of installing dependencies on startup. So, in a word, somewhat similar to a fat .jar file (e.g. that has all dependencies, vs assuming that the app server will provide some).
My problem is that sometimes it's not awfully clear how to exclude all of the stuff that you don't need.
For example, my homepage is made with Ruby on Rails, for which I have a basic container image. But to actually bundle all of the resources, I do need Python, Node (with Yarn in my case) and also a bunch of gems, so I also make a separate dev container image.
I can install all of the dependencies I need for packaging and run them in a multi-stage image, carrying over the packaged files to something based on the basic image for just running it (e.g. without Python and Node), but I still need the gems to be present and there's no obvious way to carry over only the ones I need for running a Rails app.
Even without containers, this very same pain is present in many tech stacks, even if you wanted to run software directly on the servers to which you deploy it - many stacks out there aren't really big on fully self-contained executable packages (or even ones that depend on a particular version of a runtime, like JVM or .NET, but have everything else included).
Ergo, working with Ruby, Python, Node and many others can be a bit more troublesome than it should be. Personally, containers alleviate some of those problems to a degree, at the expense of exposing that complexity to you during build time.