-
Notifications
You must be signed in to change notification settings - Fork 8.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add plugin start contract to getStartServices return value #61216
Add plugin start contract to getStartServices return value #61216
Conversation
Pinging @elastic/kibana-platform (Team:Platform) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While doing this PR, I saw that our Plugin
class contract types (TSetup
and TStart
) defaults to void
export interface Plugin<
TSetup = void,
TStart = void,
TPluginsSetup extends object = object,
TPluginsStart extends object = object
>
I was wondering if that should be changed to TSetup extends objects = {}
Upsides I see:
- more consistent, every plugin has to return a contract, even if an empty one
- some plugins are using their optional dependencies contract to check if the dependency is enabled or not. Allowing plugins to return
void
breaks this, which is atm the only way to perform such check.
Second point, should TPluginsSetup
and TPluginsStart
also defaults to {}
instead of object
?
WDYT, should I create an issue for this?
export class AlertingExamplePlugin implements Plugin<Setup, Start, AlertingExamplePublicSetupDeps> { | ||
public setup( | ||
core: CoreSetup<AlertingExamplePublicStartDeps>, | ||
core: CoreSetup<AlertingExamplePublicStartDeps, Start>, | ||
{ alerting, triggers_actions_ui }: AlertingExamplePublicSetupDeps | ||
) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would be nice if somedays TS understand that setup
is an override/implementation of Plugin.setup
to avoid having to manually redefine setup
's parameters...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It was attempted once, but it was decided that it broke too many things: microsoft/TypeScript#6118 (comment)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
They probably know better than me, however their ugly
section seems like invalid argumentation, and I don't see anything in the bad
section that wouldn't have been fixed in their example with a generic type Base<T extends Item>
. That's how that would have been achieved/fixed in any generic-using language... But anyway, they probably know better 😄
export const plugin: PluginInitializer<void, void> = () => new EmbeddableExamplesPlugin(); | ||
export const plugin: PluginInitializer< | ||
void, | ||
void, | ||
EmbeddableExamplesSetupDependencies, | ||
EmbeddableExamplesStartDependencies | ||
> = () => new EmbeddableExamplesPlugin(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm really not sure how/why, but adding the TStart
type to CoreSetup
forced to be more explicit with the setup and start dependencies when defining a PluginInitializer
. That doesn't looked to me like a bad thing though.
private readonly plugins = new Map<PluginName, PluginWrapper<unknown, Record<string, unknown>>>(); | ||
private readonly plugins = new Map<PluginName, PluginWrapper<unknown, unknown>>(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Had to do that to match the createPluginSetupContext
type in the call line 117
export class VisTypeVislibPlugin implements Plugin<Promise<void>, void> { | ||
export class VisTypeVislibPlugin implements Plugin<void, void> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unwrapped a few useless promise types as setup(core: CoreSetup, plugins: TPluginsSetup): TSetup | Promise<TSetup>
already handles it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Security/Spaces changes LGTM (with green CI).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Kibana App changes LGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Alerting changes LGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1 for the ingestManager plugin
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code LGTM - thanks @pgayvallet for adding this!
@@ -183,7 +183,7 @@ export { MountPoint, UnmountCallback, PublicUiSettingsParams } from './types'; | |||
* navigation in the generated docs until there's a fix for | |||
* https://github.com/Microsoft/web-build-tools/issues/1237 | |||
*/ | |||
export interface CoreSetup<TPluginsStart extends object = object> { | |||
export interface CoreSetup<TPluginsStart extends object = object, TStart = unknown> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We may want to add some @typeParam
docs for these now. It's not exactly obvious what should be passed in here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did not know about @typeParam
, will add.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added, however this annotation doesn't seem to be reflected in the generated doc
src/core/public/mocks.ts
Outdated
}: { | ||
basePath?: string; | ||
pluginStartDeps?: object; | ||
pluginStartContract?: object; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
super nit: doesn't technically have to be an object
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ML changes LGTM
…ervice-plugin-contract
💚 Build SucceededHistory
To update your PR or re-run it, just comment with: |
…1216) * add plugin own contract as third element of getStartServices result * adapt plugins code * update tests * revert unknown to use void again * update generated doc * fix UT * update mock to allow non-object `pluginStartContract` * add @typeparam documentation
…61415) * add plugin own contract as third element of getStartServices result * adapt plugins code * update tests * revert unknown to use void again * update generated doc * fix UT * update mock to allow non-object `pluginStartContract` * add @typeparam documentation
Summary
Fix #61106
getStartServices
return typeChecklist