Skip to content
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

Merged

Conversation

pgayvallet
Copy link
Contributor

@pgayvallet pgayvallet commented Mar 25, 2020

Summary

Fix #61106

  • Add the plugin's own start contract as a third element in the getStartServices return type
  • Adapt existing calls and cleanup a few plugin declarations

Checklist

@pgayvallet pgayvallet added the Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc label Mar 25, 2020
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-platform (Team:Platform)

@pgayvallet pgayvallet added Feature:New Platform release_note:skip Skip the PR/issue when compiling release notes v7.8 v8.0.0 labels Mar 25, 2020
Copy link
Contributor Author

@pgayvallet pgayvallet left a 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?

Comment on lines 44 to 48
export class AlertingExamplePlugin implements Plugin<Setup, Start, AlertingExamplePublicSetupDeps> {
public setup(
core: CoreSetup<AlertingExamplePublicStartDeps>,
core: CoreSetup<AlertingExamplePublicStartDeps, Start>,
{ alerting, triggers_actions_ui }: AlertingExamplePublicSetupDeps
) {
Copy link
Contributor Author

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...

Copy link
Contributor

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)

Copy link
Contributor Author

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 😄

Comment on lines -34 to +43
export const plugin: PluginInitializer<void, void> = () => new EmbeddableExamplesPlugin();
export const plugin: PluginInitializer<
void,
void,
EmbeddableExamplesSetupDependencies,
EmbeddableExamplesStartDependencies
> = () => new EmbeddableExamplesPlugin();
Copy link
Contributor Author

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>>();
Copy link
Contributor Author

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> {
Copy link
Contributor Author

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.

@pgayvallet pgayvallet marked this pull request as ready for review March 25, 2020 09:08
@pgayvallet pgayvallet requested a review from a team March 25, 2020 09:08
@pgayvallet pgayvallet requested a review from a team as a code owner March 25, 2020 09:08
@pgayvallet pgayvallet requested a review from a team March 25, 2020 09:08
@pgayvallet pgayvallet requested review from a team as code owners March 25, 2020 09:08
Copy link
Member

@azasypkin azasypkin left a 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).

Copy link
Contributor

@flash1293 flash1293 left a 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

Copy link
Contributor

@mikecote mikecote left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alerting changes LGTM

Copy link
Member

@nchaulet nchaulet left a 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

Copy link
Member

@lukeelmers lukeelmers left a 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> {
Copy link
Contributor

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.

Copy link
Contributor Author

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.

Copy link
Contributor Author

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

}: {
basePath?: string;
pluginStartDeps?: object;
pluginStartContract?: object;
Copy link
Contributor

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

Copy link
Contributor

@darnautov darnautov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ML changes LGTM

@kibanamachine
Copy link
Contributor

💚 Build Succeeded

History

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

@pgayvallet pgayvallet merged commit 468de51 into elastic:master Mar 26, 2020
pgayvallet added a commit to pgayvallet/kibana that referenced this pull request Mar 26, 2020
…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
pgayvallet added a commit that referenced this pull request Mar 26, 2020
…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
@rayafratkina rayafratkina added v7.8.0 and removed v7.8 labels Apr 6, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature:New Platform release_note:skip Skip the PR/issue when compiling release notes Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc v7.8.0 v8.0.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Discuss]: Providing plugin's own start contract from core.getStartServices