[Proposal] Option to ensure plugin hooks are executed AFTER the root CLI's hooks

[william-will-angi]

We have a root CLI set up with a handful of plugin-plugins that can be installed alongside it. Our root CLI currently has its own init hooks that need be executed.

We now want to implement some init hooks within our plugin-plugins. BUT, we want to ensure any plugin hooks are executed after the root CLI's hooks, because some of them are dependent on the setup that our root CLI provides.

In the short-term, we will likely implement a custom event (maybe called plugins:init) that plugins can use to ensure they are executed after the root CLI has initialized. There are two downsides to this approach from what I can see:

1. Plugins can no longer be utilized standalone - they will always expect the root CLI to trigger the custom event.
2. Custom business logic - Since we are using a custom event with this approach, there's a maintenance cost associated with documenting usage of this custom event and it will likely be hard to search for if problems arise.

I think it would be a bit cleaner to allow an option that ensures order is preserved. Is this a possible feature that could be implemented?

[mdonnalley]

@william-will-angi So essentially you want the option to execute hooks based on some order?

There is some precedence for this in how we determine which command to execute when two different plugins define the same command: https://github.com/oclif/core/blob/v1.9.5/src/config/config.ts#L680

The same or similar logic could be applied to hooks. It might be as simple as sorting the plugins here https://github.com/oclif/core/blob/v1.9.5/src/config/config.ts#L275

If that approach works, I don't believe either of the downsides you listed will be an issue

[william-will-angi]

Thank you for the speedy reply! Executing the hooks in a specific order is part of what we're looking for, but we also want to be able to configure resolution order as well.

For a bit more context:
We currently have an auto-updating init hook that lives in our root CLI application. This hook is async and we want to ensure that it gets run and resolved before attempting any other init hooks. So we are looking for the option to execute AND resolve hooks in a particular order.
From the second link you posted, it seems like all async hooks are executed in parallel,
which I think is a good default for the best performance assuming the hooks are designed to be independent of each other.

In general, we do want our init hooks to be independent and run in parallel, it's just this singular one that we want to make sure executes and resolves before any others.

[mdonnalley]

I see. Thanks for the clarification.

I have a few thoughts:

• We have plugin-update which handles auto updates. It also uses the init hook but there's no guard against concurrent hooks. However, it's designed to run behind the scenes (i.e. it updates the CLI while the user isn't actively using it) so it should be less of an issue. The update schedule is also hardcoded to every 14 days which may or may not work for your needs.
• Is it possible to migrate your init hooks to prerun hooks (except for the one in the root plugin)? That would ensure that the top level one is always run before any other hooks
• I could see adding an option to the oclif config for prioritizing hooks defined by the root plugin. This would tell oclif to first run hooks defined in the root plugin before going on to run all other hooks in parallel.

Generally speaking, I'd prefer if you were able to make either of the first two work for you since it would mean less code to maintain and fewer features to document. But if you decide you need the 3rd option or some variation of it, you'll need to submit the PR yourself as we don't have the ability to prioritize it on our side at this time. However, I'm more than happy to review it whenever it's ready