Allow custom CLI commands to be added by extensions

[smilledge]

✨️ Improvements

• Added hooks to support custom CLI commands in extensions
• Hooks will now be called when using the CLI (eg, item hooks, user hooks, etc)

🐛 Bugfixes

• Fix typescript errors in the shared package (the api package has stricter tsconfg which caused errors in tests)

⚠️ Risks

• Previously hooks weren't called from CLI commands (eg, creating a user now triggers user.create.before). However, I think this should be the expected behaviour?
  
• There may be additional console logs from loading extensions (depending on log level). This might be problematic if someone was depending on specific CLI output form a command.
  

[rijkvanzanten]

@nickrum Thoughts on this vs cli commands as an extension type? It's a strange mix 🤔 Theoretically, you could do custom endpoints through a custom hook as well by attaching to the app init hook. Maybe custom endpoints should just be another hook? Food for thought!

[nickrum]

@rijkvanzanten I'd rather have it as a separate extension type. Right now, hooks are only meant for one-off actions at certain points within the lifecycle of Directus or to alter data-flow at certain user-triggered events. If we start to allow adding "additional functionality" through hooks, this breaks separation of concerns. It makes it much harder to reason, where new features are coming from.

Also, IMO the CLI integrated into the API is only meant for the bare minimum of commands necessary to make the Directus API usable. I'm not sure, if we should even support extending it at all.

[smilledge]

IMO there's lots of valid reasons for extending the CLI. Some of my current use cases are;

• Database seeding
• Exporting & migrating collection metadata
• Custom import & export scripts

Currently I'm just using a separate commander instance and importing the Directus API (eg, database, services, etc). This works, but it does have some disadvantages;

• You don't get access to the Directus programmatic API
  • And it feels wrong to be importing modules with paths like directus/dist/utils/get-schema
• It's messy and complicates the dev workflow 😅

Also, I think having the ability to add REST API endpoints using hooks is important too. Some situations where I'm currently using the routes.init hook over custom endpoints are;

• Endpoints that need a specific path for compatibility with other systems and tools (eg, /healthz)
• Replacing other systems with Directus while maintaining backwards compatibility

[smilledge]

An alternative to adding CLI hooks could be to export the commander program in a way that it can be imported and extended. For example;

if (require.main === module) {
    createCli().parseAsync(process.argv).catch(...);
}

export function createCli(): Command {
    ...
}

[rijkvanzanten]

If we start to allow adding "additional functionality" through hooks, this breaks separation of concerns. It makes it much harder to reason, where new features are coming from.

I agree, but I see that as 100% user-risk. We don't actively recommend nor demonstrate that way of injecting custom logic, but it's a very nice escape hatch to have for power users that know what they're doing (as demonstrated by @smilledge). I'm down with this addition 👍🏻

One point of concern you brought up earlier today @nickrum is the fact that this change requires the extensions to be initialized even though its only for the single CLI invocation. Is that a technical problem, or just something we need to take into account moving forwards?

[rijkvanzanten]

LGTM

[nickrum]

• Endpoints that need a specific path for compatibility with other systems and tools (eg, /healthz)
• Replacing other systems with Directus while maintaining backwards compatibility

With the recent changes to endpoints, you should be able to do this with a custom endpoint as well.

One point of concern you brought up earlier today @nickrum is the fact that this change requires the extensions to be initialized even though its only for the single CLI invocation. Is that a technical problem, or just something we need to take into account moving forwards?

Just something to take into account, especially concerning the upcoming changes that are necessary for OTA installation.