This lets us or anyone modify the path from where dependencies (usually
installed into /vendor by Composer) are loaded. We need to be able to
tweak this in our integration tests, where the application code under
test needs access to certain dependencies.
This is probably the most complicated way I could find to fix#1587.
Jokes aside, this was done with a few goals in mind:
- Reduce coupling between the installer and the rest of Flarum's
"Application", which we are building during installation.
- Move the installer logic to several smaller classes, which can then
be used by the web frontend and the console task, instead of the
former hacking its way into the latter to be "DRY".
- Separate installer infrastructure (the "pipeline", with the ability
to revert steps upon failure) from the actual steps being taken.
The problem was conceptual, and would certainly re-occur in a similar
fashion if we wouldn't tackle it at its roots.
It is fixed now, because we no longer use the ExtensionManager for
enabling extensions, but instead duplicate some of its logic. That is
fine because we don't want to do everything it does, e.g. omit
extenders' lifecycle hooks (which depend on the Application instance
being complete).
> for each desired change, make the change easy (warning: this may be
> hard), then make the easy change
- Kent Beck, https://twitter.com/kentbeck/status/250733358307500032Fixes#1587.
Casting an object to an array does not have the intended effect of
wrapping the object in an array. Instead we need to explicitly check
if the returned value is an array or not.
The gathering and execution of extenders can actually be done here
in the `Extension` class. This way, the `ExtensionManager` only
deals with the question of which extensions are enabled, the
`Extension` class actually extends the core application, and the
service provider simply calls a method, without having to know
about internals.
Turns out Container::call() does not work with invokable classes.
Thus, we need to wrap callables in a custom extender class to
support injecting any resolvable type-hint automatically.
Refs #851.
This simplifies the API and gives extension developers more
flexibility, for a) maintaining backwards compatibility, and
b) doing advanced stuff that extenders do not allow.
Note that only extenders are guaranteed to work across
different versions of Flarum (once the API surface is stable).
See the discussion in https://github.com/flarum/core/pull/1335.
Loading the activated extensions now means retrieving an array of
extenders (classes that implement a certain type of extension of a core
feature in Flarum).
For now, the only existing extender is the Compat extender which is used
to handle old-style bootstrappers that simply return a closure that
receives all of its dependencies via auto injection.
In the future, extensions will be able to return an array of extender
instances from their bootstrapper instead. These extender classes will
be implemented in the next step.
When running migrations for an extension without any migrations (eg.
BBCode), the migration notes for the previous extension were being
displayed, because the Migrator never had a chance to clear them.
