mirror of
https://github.com/elastic/kibana.git
synced 2025-06-27 10:40:07 -04:00
5a68f70900
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com> Co-authored-by: amyjtechwriter <61687663+amyjtechwriter@users.noreply.github.com>
26 lines
1.1 KiB
Text
26 lines
1.1 KiB
Text
[[core-packages]]
|
|
== Core packages
|
|
|
|
experimental[]
|
|
|
|
Core packages have well defined boundaries, have a single responsibility, and are organized by domain. Core packages follow a specific naming schema, according to what they contain:
|
|
|
|
For example, core capapability packages are:
|
|
|
|
* `core-capabilities-browser-internal`
|
|
* `core-capabilities-browser-mocks`
|
|
* `core-capabilities-common`
|
|
* `core-capabilities-server`
|
|
* `core-capabilities-server-internal`
|
|
* `core-capabilities-server-mocks`
|
|
|
|
Each domain has a specific package for public types, which can be imported and used throughout the Kibana codebase including in its implementation and unit tests. These packages are internal to core and not intended for public use, but they can be used by plugins to create mock versions for unit testing.
|
|
|
|
In addition, domains contain separate packages for the client-side and server-side and, in some cases, a base, that
|
|
supports both client and server needs. When a domain shares code between the server and client, that code lives in
|
|
a `common` package. Mocks have their own dedicated package.
|
|
|
|
All of core's public API's have inline `jsdocs` that include examples as nescessary.
|
|
|
|
|
|
|