maxmustermann/kibana
1
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Add links to conventions doc from migration guide (#51104)

Browse source
This commit is contained in:
Josh Dover 2019-12-16 10:26:02 -06:00 committed by GitHub
parent 3137b07b57
commit 09faf19812
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
1 changed files with 5 additions and 3 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

8
src/core/MIGRATION.md
View file

@ -64,7 +64,7 @@ We'll start with an overview of how plugins work in the new platform, and we'll
Plugins in the new platform are not especially novel or complicated to describe. Our intention wasn't to build some clever system that magically solved problems through abstractions and layers of obscurity, and we wanted to make sure plugins could continue to use most of the same technologies they use today, at least from a technical perspective.
New platform plugins exist in the `src/plugins` and `x-pack/plugins` directories.
New platform plugins exist in the `src/plugins` and `x-pack/plugins` directories. _See all [conventions for first-party Elastic plugins](./CONVENTIONS.md)_.
### Architecture
@ -109,7 +109,7 @@ export function plugin(initializerContext: PluginInitializerContext) {
}
```
**[3] `public/plugin.ts`** is the client-side plugin definition itself. Technically speaking it does not need to be a class or even a separate file from the entry point, but _all plugins at Elastic_ should be consistent in this way.
**[3] `public/plugin.ts`** is the client-side plugin definition itself. Technically speaking it does not need to be a class or even a separate file from the entry point, but _all plugins at Elastic_ should be consistent in this way. _See all [conventions for first-party Elastic plugins](./CONVENTIONS.md)_.
```ts
import { PluginInitializerContext, CoreSetup, CoreStart } from 'kibana/server';
@ -215,7 +215,7 @@ These are the contracts exposed by the core services for each lifecycle event:
Plugins can expose public interfaces for other plugins to consume. Like `core`, those interfaces are bound to the lifecycle functions `setup` and/or `start`.
Anything returned from `setup` or `start` will act as the interface, and while not a technical requirement, all Elastic plugins should expose types for that interface as well. 3rd party plugins wishing to allow other plugins to integrate with it are also highly encouraged to expose types for their plugin interfaces.
Anything returned from `setup` or `start` will act as the interface, and while not a technical requirement, all first-party Elastic plugins should expose types for that interface as well. 3rd party plugins wishing to allow other plugins to integrate with it are also highly encouraged to expose types for their plugin interfaces.
**foobar plugin.ts:**
@ -1095,6 +1095,8 @@ The benefit of this approach is that the details of where code lives and whether
A plugin author that decides some set of code should diverge from having a single "common" definition can now safely change the implementation details without impacting downstream consumers.
_See all [conventions for first-party Elastic plugins](./CONVENTIONS.md)_.
### When does code go into a plugin, core, or packages?
This is an impossible question to answer definitively for all circumstances. For each time this question is raised, we must carefully consider to what extent we think that code is relevant to almost everyone developing in Kibana, what license the code is shipping under, which teams are most appropriate to "own" that code, is the code stateless etc.