Now that I notice this:
I think you may have an easy out, which is that the application takes precedence over all addons, so it’s safe to always provide your default file in AddonDocs’s
But if you want to go deeper…
One thing about broccoli is that nearly everything is pull based. The whole graph is constructed first, and then actual work happens as each tree is read. And the work can be asynchronous. The
treeFor methods are called in plugin order, but that is just the graph construction phase.
You can’t really guarantee order between two broccoli transforms unless there is some dependency between them. This is a feature, not a bug, because it leaves the build system free to determine when/if to run any particular transform stage. Once you start to consider arbitrary incremental rebuilds, one can see that it needs to be this way.
So if you really find yourself caring about the relative order of two transforms, you should be looking to refactor so that one actually depends on the other explicitly.
But here is where your question gets murky. When an addon processes
treeForApp, all the inputs to that function are things from the addon itself. It doesn’t get to see anything from the app anyway. The default behavior of
treeForApp is just to return everything that was in the addon’s
app folder (which is typically just re-exports as written by the component blueprint, etc).
To put it another way, I think you were imagining that each addon’s treeForApp composes something like:
But in reality it is more like
mergeTrees([treeForApp(), treeForApp(), treeforApp(), originalApp])
So even if you manipulate the relative order of the addons, you are only changing the order of the merge, you’re not establishing any data dependency between the addons.