@benjamn I assume you are most familiar with the 1.3 changes as you did most of them Do you know why my app payload grew substantially after upgrading?
@ryanswapp, it might help to list your npm modules & atmosphere packages
Does anyone know if there is a way to add some statistics into the build system to monitor this? It would be great to be able to test for this and fail the build if the payload becomes bigger than x size
The thing is, importing modules into different places can cause code duplication on the bundle, but since gzipping mitigates the duplication, the end result that actually that gets sent down to the client is only negligibly larger.
Sort the newly created files by size and crack open the largest file:
ls -l xx* | sort -r | more
The minified Meteor JS file splits most packages/modules up by blank lines, so this will at least allow you to narrow in on the biggest culprit. Open any of the files and look at the last few characters of the file - in most cases you’ll see something like ...Package["forwarder:autoform-wizard"]... to help give you a hint.
@hwillson You’re the man! I wish I was a little better at bash utils… Hopefully I’ll get there some day. It looks like the entire lodash library is being pulled in. I will have to investigate and see what the issue is… Thanks for your help!
@serkandurusoy Ya I’m pulling in just the lodash methods that I need (e.g. import assignIn from ‘lodash/assignIn’). In looking at the bundle more closely I think that underscore may be the issue. I’m not pulling it in but some of my dependencies are. In addition, it looks like the Meteor build system may be pulling in multiple copies of underscore and other libraries. I count at least 5 copies of tracker and over 10 copies of underscore…
Also, if you are using devdependencies in your package.json, it seems like they will be included in your final bundle,
check the open issue https://github.com/meteor/meteor/issues/6836 for more details. One proposed solution would be to install npm packages with npm install --production before building and deploying. I still haven’t tried though
Thanks for the links! I just gave the workaround a go and the results were interesting… I’m using mupx to deploy and without the workaround the payload comes in 991kb. With the workaround the payload of the app is 1.3mb. Isn’t that bizarre? Perhaps mupx is already doing some kind of production build optimizations for 1.3. I guess I’ll keep looking for the culprit of my payload bloat
@tcastelli Yikes! That’s not a fun bug. Fortunately I don’t have any devDependencies declared in the package.json. I’ll be sure to avoid any for the time being.