Curious why Deploy takes 3 times longer, after update to Meteor 1.3?


#1

Not a big deal, necessarily. But I’d be interested to know what’s actually going on that’s taking so much longer when I deploy?

Note: this applies to deploys after already updated & deployed Meteor…

FYI, deploying to Galaxy.


#2

I would be curious to know as well. I have a webpack app that is running 1.3 beta and it’s taking forever and a day to upload to modulus as well.


#3

Did anyone check the size of the generated bundle (from meteor build) for the same project in either version? I mean, is the bundle suddenly much bigger (and if so, how much and why?) or is there a less obvious reason for this?


#4

Hi,

I ran a meteor build on my medium sized app and ended up with a 30M bundle size (compressed)

the node_modules directory is the biggest in size > 100M

meteor package being the heaviest: 40M

I also noticed that my --dev-dependencies packages are included as well - which I found … unnecessary

would really like to know how this compares to others

thanks


Upgrading to 1.3 made javascript payload size double
#5

This is a known issue on Github: https://github.com/meteor/meteor/issues/6750

Looks like it will hopefully get fixed in a future 1.3.x release.

A current workaround as provided by Ben Newman:

To that end, I recommend you run

mv node_modules .node_modules.backup
meteor npm install --production

in your app before running meteor build, so that you don’t have to copy the devDependencies. Then the node_modules directory will only be 46MB, and the copy should take 8% as long as it did before.


Upgrading to 1.3 made javascript payload size double
#6

I am using a separate git worktree for builds at the moment (sometimes I use a dedicated build machine, but the worktree is handy when building on my machine).

This basically gives you another working directory that stems from the same repository without overhead or the need to sync. I checkout the desired commit (detached head mode) and build.

This way I keep may development dependencies in my workdir and have the production node modules in the alternative worktree directory.

Build times are significantly shorter: 25+ mins with the full packages and ~2 mins with the production version, which is in line with what Ben specified. The bundle is also much smaller.


#7

Thanks for the replies,

I’ll try the workaround asap