In the project I am working on we have implemented a complex structure of meteor apps and packages. Lately, we achieved to improve the build performance and get consistently 8-10 seconds per code change. However, we think that according to our current project size, it could be improved even more. There is probably something that we do wrong on referencing our code.
Recently, we provided more features to the app, which resulted on include new dependency branches, referencing to modules implemented on the app and packages. But the rebuild timing raised up to 20 seconds on code change. We don’t understand what has been wrong, but according to our current research, we’d want to point possible causes, and confirm with you if those has been a problem for you. The changes required can get us to do high efforts and we’d want first to get more feedback on real causes and understanding on the meteor builder.
Circular dependencies on our dependency tree
By comparing the codebase state when we got 8 seconds per code change to the 20 seconds one, we have noted with madge cli that some of our packages introduce more circular dependencies. So our first state already have some of them but the new one gets even more. The modules that produce them are related with business logic (collections, models and etc), so I guess we should consider strategies to remove those like commented here if they have impact on builds.
- Are circular dependencies a real issue for meteor builder to resolve the bundle? That could explain the timing we have got ever, but also we are aware that in ES6 are handled, so not 100% sure.
References to packages module and submodules
In order to get less weight bundles and supposedly reload times, we use specific paths to package submodules, so:
instead of
import { myModule } from 'meteor/example-package'; // api.mainModule usage
we use
import { myModule } from 'meteor/example-package/modules';
// or
import myModule from 'meteor/example-package/modules/my-module';
- Does this have any impact on the meteor builder to resolve the bundle?
- Could the cache be affected somehow and on using references like these the builder is not optimistic and need to resolve them again?
There are probably more things going on which we are trying to analyze and we will report, but for the moment we’d want to mention such items in case someone has a clear idea on how the meteor builder resolve those.
By the way, does it exist a tool for debugging the meteor builder? That could be cool to deep into the real causes quickly.