github-mirrors/kibana
1
0
Fork 0
mirror of https://github.com/elastic/kibana.git synced 2025-06-27 10:40:07 -04:00
Code Issues Projects Releases Packages Wiki Activity

implement "plugin" package type (#149370)

Browse source 
This PR updates the core discovery logic to support loading plugins from
packages. This logic is additive, so that the existing plugins in the
repo and third-party plugins can continue to be loaded via the existing
mechanism, but with https://github.com/elastic/kibana/pull/148130 we
will be automatically migrating all plugins in the repo to packages,
which will use this logic.

The logic is already in-use in that PR, and was developed there, but
extracted here for easier review.

The logic is relatively simple, where a list of packages in the repo are
attached to the core `Env` and then filtered by core before converting
all plugin packages to `PluginWrapper`. The `PluginWrapper` still
exposes the plugin manifest to the rest of the code, and it is used in
many places, so rather than making changes to the `PluginWrapper` I'm
faking a legacy plugin manifest with the plugin package manifest.

@elastic/kibana-core: I'm going to need some help identifying what we
need to get test coverage for. This is a pretty simple addition to the
core IMO, and if it didn't work then nothing would work, so I'm pretty
confident in it, but would still appreciate your feedback.
This commit is contained in:
Spencer 2023-01-30 10:47:53 -07:00 • committed by GitHub
parent ad75d900c9
commit 376bed5d16
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
31 changed files with 521 additions and 128 deletions
Download patch file Download diff file Expand all files Collapse all files

18
dev_docs/operations/packages_idm.mdx
View file

@ -51,19 +51,16 @@ Package types allow us to have many different packages, pre-defined build tasks,
: These packages can be imported from all other packages.
`shared-browser`
: These packages can be imported from `shared-browser` and `plugin-browser` packages. `shared-browser` packages may include Storybooks.
: These packages can be imported from `shared-browser` and `public` directories within `plugin` packages. `shared-browser` packages may include Storybooks.
`shared-server`
: These packages can be imported from `shared-server` and `plugin-server` packages.
: These packages can be imported from `shared-server` and `server` directories within `plugin` packages.
`shared-scss`
: These packages can be imported by `shared-browser` and `plugin-browser` packages, and expose an `index.scss` file to consumers instead of an `index.ts` file.
: These packages can be imported by `shared-browser` and `public` directories within `plugin` packages, and expose an `index.scss` file to consumers instead of an `index.ts` file.
`plugin-browser`
: These packages expose types to other packages via a root `types.ts` file. Module IDs must end with `-plugin-browser`. Consumers must use `import type` statements.
`plugin-server`
: These packages expose types to other packages via a root `types.ts` file. Module IDs must end with `-plugin-server`. Consumers must use `import type` statements.
`plugin`
: These packages were automatically created from the existing plugins at the time we switched everything over to packages. Module IDs must end with `-plugin`. Consumers must use `import type` statements.
`functional-test`
: These packages expose one or more functional testing configurations, including API integration tests, and can not be imported by other packages. Separating functional and integration tests allows us to iterate on tests without rebuilding the application. Similarly, iterating and updating the application should mostly mean the tests don't need to rebuild.
@ -160,8 +157,7 @@ The solution to resolving a circular dependency has, thus far, been to break out
There are a few package naming rules:
- all packages must use the `@kbn/` namespace
- `plugin-browser`-type packages must end with `-plugin-browser`
- `plugin-server- type packages must end with `-plugin-server`
- `plugin`-type packages must end with `-plugin`
- considering that we operate in a global namespace, avoid overly generic names
Other than these rules, it's up to you and your team to decide on an appropriate name for your package.
@ -205,4 +201,4 @@ We're now entering Phase 2 of the plan, more details about the phases of our pla
[status]: #what-works-now
[idm-rfc]: https://docs.google.com/document/d/1Bhg601MoGQjqGMGdLWSLnkopRexwrcbf_0MNcUkhx3I "Internal Dependency Management RFC on Google Docs"
[pkgDirs]: https://github.com/elastic/kibana/blob/main/packages/kbn-bazel-packages/src/bazel_package_dirs.ts#L22
[pkgDirs]: https://github.com/elastic/kibana/blob/main/packages/kbn-repo-packages/src/repo_package_dirs.js#L19