The rebuild times of my app are getting painfully slow. This has a drastic impact on my overall productivity, especially if I compare it to my Webpack apps. I don’t expect magic, but any hints on improving / speeding up rebuild times is highly appreciated.
(I’m still on 1.5, since I have problems building my app on iOS with 1.6, but a quick test with 1.6 didn’t show any noticeable build improvements anyways.)
Thanks for sharing your insights. Highly appreciated!
ad 1: I’m doing this regularly, also because it solves some weird problems with tap:i18n
ad 2: This is given in my app, because I am using local packages that clearly define which code goes where.
ad 3: Didn’t know about the profiling options, that’s cool. Will try it out.
Quick note about the bundler-cache; as of Meteor 1.5, it should no longer grow to infinity! As long as you’ve cleared out your old cache files at least once since updating to Meteor 1.5+ (or you’ve started a new app since Meteor 1.5), then you shouldn’t have to worry about the bundler-cache files anymore. For more info see:
I’m also seeing local packages as a major slowdown, I decided to track it down today and I seem to loose 10 seconds on every rebuild in the ‘prepareProjectForBuild’ step, because meteor is running npm on every file change inside a package: https://github.com/meteor/meteor/issues/9381
Unfortunately, this is not an option for me. I am re-using most of my packages across different apps, so I am heavily relying on Meteor’s packaging system (which is pretty cool, especially in combination with a central package repository). But I already feared that my high loading times might be somewhat related to using Meteor packages.
But I wasn’t sure if I was actually affected by this, since I am not using Npm.depends() that much anymore. Main reason is that the npm packages are duplicated if they are referenced in more than one Meteor package this way.
Yeah, but I like packages being self-contained, stating their own dependencies.
Also if I recall correctly, globally installed babel modules don’t work for packages.
Anyway, I don’t know if having a lot or little matters that much. I think as soon as you have one you can loose quite a bit of time. But maybe your profile data shows something else. Might be interesting to post that since they’re very informative.
I was planning to a split a relatively large code base to local packages in order to allow reuse across projects. Right now I have no noticeable build delay but it seems given this thread that I might introudce some by migrating to package based architecture.
Should I be concerned? It’s unfortunate because I’m finding meteor packaging system very interesting since it’s allowing me to slice the code base vertically and package a feature (components, pages, collections and api!) and reuse it in another project which is a huge productivity boost and cost saving.