Pruning / Shrinking Bundle. It's 125meg!

#1

I have a relatively small meteor app. Probably not more than 5000 lines including css/html/js. It uses a few packages like iron:router and accounts-???. When I build the bundle it’s 125meg!! Checking the build folder I see lots of compile time dependencies are in there (babel, eslint, coffeescript, …).

While I can manually try to delete them is there any meteor command/option to pair this stuff down? Basically uploading 125meg to my live server seems like a waste. Of course the tar.gz as smaller (40meg) but that’s still 40 meg to upload and then decompress into 125meg.

Of course at one level 125meg is not that big and I don’t deploy every day. On the other hand lots of small files get padded out to sectors. My mac says “254mb space used on disk” for example. I’m sure it’s the same on the server.

Even for dev it’s not fun. Sure, locally I can run directly from the build folder but then for staging it’s a several minute upload every time to test. I can send the source and build on the staging server but that’s not really a help. The build takes minutes, tons of memory, and all the build deps get installed so it doesn’t actually save any space it only saves upload time. Iteration time is actually slower because of build times.

The only thing I could think of is trying to run npm prune --production but that failed. Maybe I don’t know where to run it. Tried running in in build/bundle/programs/server and got an error error May not delete: build/bundle/programs/server/node_modules/.bin. Even looking at the package.json in that folder it’s not clear it would have deleted much.

Are there any known solutions short of manually deleting folders?

Anything that could make iteration when uploading faster and smaller would be great!


To answer my own question I started using rsync to upload. Doesn’t help the disk space issues but does help just push the smallest number of changes.

#2

Have you tried the bundle-visualizer tool?

1 Like
#3

Double check your package.json, to make sure dev-only dependencies are in the devDependencies section and not the dependencies section.

#4

Is that useful? I don’t manage the package.json, meteor does.

And as far as direct dependencies, the ones that meteor put in the package.json in the root of my project folder there are only 2 dependencies and 0 devDependencies. bcrypt and babel-runtime.

It’s meteor itself or meteor packages that are adding all the other dependencies.

Checking the build folder the biggest modules are all in build/bundle/programs/server/npm/node_modules/meteor. They are “loopback_dropdowns” (no idea what that is, not something I added directly)". It by itself is 40meg (because it includes a ton if build related stuff). Next up is “reywood_iron-router-ga” at 16meg (because it includes eslint). Followed by “iron-router” 9meg (because it includes grunt), babel-compiler 8 meg, http 5meg, meteorhacks_inject-initial 4meg and they get smaller quick from there. Those first packages are responsible for 2/3rds of the space. The next 14 collectively take about 14meg

#5

devDependencies are esential as they won’t be put into production build. If you have things like eslint in the production build then you have installed all dependencies with the ---save instead of --save-dev flag.
package.json is managed by npm, running it via the meteor npm command ensures that the appropriate version of the package is installed (appropriate to the meteor version of node) and that you don’t need to have node and npm installed on your system since that is included in Meteor. The file is easily accessible and readable, you can easily edit it by hand (to move things around). Check the npm docs.

#6

There are only 2 deps, bcrypt and bable-runtime and zero devDependencies.

other deps COME FROM METEOR not me. eslint, babel-compiler, etc are nothing I added. As an example you can build the sample TODO app and it will come out to 40meg!

#7

Simple TODO app is 728kb. 40MB seems quiet a stretch to me.

Try adding meteor-node-stubs npm package, but even that should be there by default, and double checking your babel settings.
Which version of Meteor are you using? The only thing I can think of is if you are by a chance not running dev version of Meteor (installed from Github).
When you inspect your production code, is it minified?

#8

It’s important to distinguish between the total bundle size (40 seems correct - ours are 50 for our smallest and 93 for our largest) and client bundle size which is what the visualiser shows you and what each client will download.

2 Likes
#9

728k used, but the bundle itself is 40meg. There’s no command that I know of that pulls out the 728k used so you don’t have to upload a 40meg bundle just to use 728k of that 40meg bundle.

#10

As long as you are getting something managable to the client that is the most important thing. For my app in the current production iteration the stats are:
Total Bundle Size 63.47 MB
Client Bundle Size 2.77 MB

Can you tell us which version of Meteor and which packages you are using? So that we can eliminate the easiest culprits.