Prepare all the things

[sidvishnoi]

[marcoscaceres]

Can you help me understand a bit more of what we want to achieve here? The original plugin design was to allow anything synchronous (e.g., preloading, loading styles, etc) in the module to happen independently, in parallel, and in a mostly indeterministic manner to every other module.... maybe that was a bad thing? I'm worried that prepare() puts us back into a linear plugin execution order, although maybe the determinism of calling .prepare() might be good in places?

[sidvishnoi]

I'm worried that prepare() puts us back into a linear plugin execution order, although maybe the determinism of calling .prepare() might be good in places?

All prepare calls are non-blocking (yet serially deterministic), so we won't get a bad form of linear plugin execution order. That is, no prepare call will cause a slowdown.

As we've access to conf and state, we can start some requests earlier in parallel without waiting on other plugins. So we should get faster processing instead of "slow as in serial". (See core/a11y here and core/caniuse earlier as examples)

It'll also add consistency in how plugins and their state are managed. For example with core/biblio: earlier even if we called core/biblio late in plugin order, its dependencies still did await biblio, adding a convulated serial order. With conf.state and prepare, only the plugin order in profiles determines what's available to subsequent plugins, which is much cleaner.

It terms of clarity, also see how we removed an unnecessary async-await with resolveRef.

[marcoscaceres]

I'm not really liking the conf.state thing... could each plugin just export its own state instead?

[marcoscaceres]

As we've access to conf and state, we can start some requests earlier in parallel without waiting on other plugins. So we should get faster processing instead of "slow as in serial". (See core/a11y here and core/caniuse earlier as examples)

I like this idea in principle.