Meteor build - ignore node_modules

I’m confused why the meteor build system is trying to tar gzip the node_modules folder?
Since the README itself states one must cd to the programs/server and run npm install.

If you have a large project, the build time is well over 15 to 20 minutes.
And the output gzip is 90+ mb, which expands to over 200 mb.
Hell, even the base-project (“meteor create myapp”) is 20+mb and over 5 minutes to build.
Strip away node_modules and it’s less than 2mb.

If we are running npm on the server anyway, why are we zipping up node_modules?
And why can’t I tell meteor to stop doing that?
I’m thoroughly tired of staring at a black box as meteor chunks through millions of files. Thoroughly.
The whole reason npm exists is to manage that folder. Just silly, and ruining my ssd’s max cap.

Why is meteor zipping it up?
Can anyone explain this savage brutal inane anti-pattern behavior to me.
Was it engineered before package-lock.json existed, and thus nobody bothered to upgrade? Seriously.


Well, original engineering was before package-lock existed. But @benjamn or @zodern will know more about this.

1 Like

I do apologize for my frustration, clearly seen, was a long day.
I have a lot of love and respect for meteor.
It’s just painful at times with the node_modules aspect.

Not sure if that is something on the future track list or not to improve upon.


Yeah - this seems pretty bad. Any update on this one? Does deploying to galaxy omit the node_modules folder? My tarball clocked in at 577 mb – sheesh.

Theres always a tradeoff. By tarring all the node modules you pay the price of the install only once, some packages take quite a long time to install (separate from their download time) and once they are present don’t need to be installed again. The reason for the install being “required” on the server is in the case that your build machine is running in a different environment to your server. (e.g., windows vs Linux or different kernel versions) if your environments are the same I believe you can entirely skip this step.

A similar tradeoff exists when you dockerize your meteor application, by installing all your dependencies up front, and creating a giant image, you don’t need to npm install when you start the container which minimizes downtime on restart.

That being said, the presence of the dev modules is truly horrible. If you add pupeteer or nightmare js you end up deploying an entire chrome install to your server :frowning:


Seems like a case that can be given as an option to the developer through an additional command line params e.g. --no-node-modules