mirror of
https://github.com/elastic/kibana.git
synced 2025-04-25 18:27:59 -04:00
b24fdf5d3f
## Summary This PR is part of the Kibana Sustainable Architecture effort. The goal is to start categorising Kibana packages into _generic platform_ (`group: "platform"`) vs _solution-specific_. ``` group?: 'search' | 'security' | 'observability' | 'platform' visibility?: 'private' | 'shared' ``` Uncategorised modules are considered to be `group: 'common', visibility: 'shared'` by default. We want to prevent code from solution A to depend on code from solution B. Thus, the rules are pretty simple: * Modules can only depend on: * Modules in the same group * OR modules with 'shared' visibility * Modules in `'observability', 'security', 'search'` groups are mandatorily `visibility: "private"`. Long term, the goal is to re-organise packages into dedicated folders, e.g.: ``` x-pack/platform/plugins/private x-pack/observability/packages ``` For this first wave, we have categorised packages that seem "straightforward": * Any packages that have: * at least one dependant module * all dependants belong to the same group * Categorise all Core packages: * `@kbn/core-...-internal` => _platform/private_ * everything else => _platform/shared_ * Categorise as _platform/shared_ those packages that: * Have at least one dependant in the _platform_ group. * Don't have any `devOnly: true` dependants. ### What we ask from you, as CODEOWNERS of the _package manifests_, is that you confirm that the categorisation is correct: * `group: "platform", visibility: "private"` if it's a package that should only be used from platform code, not from any solution code. It will be loaded systematically in all serverless flavors, but solution plugins and packages won't be able to `import` from it. * `group: "platform", visibility: "shared"` if it's a package that can be consumed by both platform and solutions code. It will be loaded systematically in all serverless flavors, and anybody can import / use code from it. * `group: "observability" | "security" | "search", visibility: "private"` if it's a package that is intented to be used exclusively from a given solution. It won't be accessible nor loaded from other solutions nor platform code. Please refer to [#kibana-sustainable-architecture](https://elastic.slack.com/archives/C07TCKTA22E) for any related questions. --------- Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com> |
||
|---|---|---|
| .. | ||
| src | ||
| index.ts | ||
| jest.config.js | ||
| kibana.jsonc | ||
| package.json | ||
| README.mdx | ||
| tsconfig.json | ||
--- id: kibDevDocsOpsSomeDevLog slug: /kibana-dev-docs/ops/kbn-some-dev-log title: "@kbn/some-dev-log" description: 'LCD types for several dev-focused loggers' date: 2022-07-14 tags: ['kibana', 'dev', 'contributor', 'operations', 'packages', 'scripts', 'logging'] --- `@kbn/some-dev-log` implements lowest-common denominator types for several loggers that we use in development tooling. In order for commonly used tools to accept either log instance we need a common interface for them to implement which gives enough functionality to get the job done but doesn't require implementing a bunch of fancy features in all loggers. The interface mostly follows the `console.log()` interface, allowing you to pass a string as the first argument and then anything afterwards. The arguments are converted to a string by all loggers using [`util.format()`](https://nodejs.org/api/util.html#utilformatformat-args) from the standard library. Currently, the loggers implementing this type are: - <DocLink id="kibDevDocsToolingLog" />: The majority of dev tasks should use this log and it is automatically provided by the common dev-task wrapper provided by <DocLink id="kibDevDocsOpsDevCliRunner" />. - <DocLink id="kibDevDocsOpsKbnPm"/> `Log` class: `@kbn/pm` runs before the repository is bootstrapped and needs a logger to use before other packages are available, so we have a separate and simple log implementation that code which implements the `SomeDevLog` class. Other code in the repository should rarely need to use this class or even know of it's existance. Unless your package needs to be used by `@kbn/pm` there is little reason you should need to use this type, but it might be a good idea to use this type if there's a chance we might need to use your package in the future.