## Summary
This PR aims at relocating some of the Kibana modules (plugins and
packages) into a new folder structure, according to the _Sustainable
Kibana Architecture_ initiative.
> [!IMPORTANT]
> * We kindly ask you to:
> * Manually fix the errors in the error section below (if there are
any).
> * Search for the `packages[\/\\]` and `plugins[\/\\]` patterns in the
source code (Babel and Eslint config files), and update them
appropriately.
> * Manually review
`.buildkite/scripts/pipelines/pull_request/pipeline.ts` to ensure that
any CI pipeline customizations continue to be correctly applied after
the changed path names
> * Review all of the updated files, specially the `.ts` and `.js` files
listed in the sections below, as some of them contain relative paths
that have been updated.
> * Think of potential impact of the move, including tooling and
configuration files that can be pointing to the relocated modules. E.g.:
> * customised eslint rules
> * docs pointing to source code
> [!NOTE]
> * This PR has been auto-generated.
> * Any manual contributions will be lost if the 'relocate' script is
re-run.
> * Try to obtain the missing reviews / approvals before applying manual
fixes, and/or keep your changes in a .patch / git stash.
> * Please use
[#sustainable_kibana_architecture](https://elastic.slack.com/archives/C07TCKTA22E)
Slack channel for feedback.
Are you trying to rebase this PR to solve merge conflicts? Please follow
the steps describe
[here](https://elastic.slack.com/archives/C07TCKTA22E/p1734019532879269?thread_ts=1734019339.935419&cid=C07TCKTA22E).
#### 9 packages(s) are going to be relocated:
| Id | Target folder |
| -- | ------------- |
| `@kbn/cbor` | `src/platform/packages/shared/kbn-cbor` |
| `@kbn/repo-info` | `src/platform/packages/shared/kbn-repo-info` |
| `@kbn/repo-packages` |
`src/platform/packages/private/kbn-repo-packages` |
| `@kbn/rison` | `src/platform/packages/shared/kbn-rison` |
| `@kbn/ui-shared-deps-npm` |
`src/platform/packages/private/kbn-ui-shared-deps-npm` |
| `@kbn/ui-shared-deps-src` |
`src/platform/packages/private/kbn-ui-shared-deps-src` |
| `@kbn/ui-theme` | `src/platform/packages/shared/kbn-ui-theme` |
| `@kbn/utility-types-jest` |
`src/platform/packages/shared/kbn-utility-types-jest` |
| `@kbn/utils` | `src/platform/packages/shared/kbn-utils` |
<details >
<summary>Updated references</summary>
```
./kbn_pm/src/lib/bazel.mjs
./kbn_pm/src/lib/external_packages.js
./package.json
./packages/core/rendering/core-rendering-server-internal/src/bootstrap/get_theme_tag.ts
./packages/kbn-babel-register/BUILD.bazel
./packages/kbn-eslint-plugin-imports/src/helpers/groups.ts
./packages/kbn-monaco/BUILD.bazel
./packages/kbn-plugin-helpers/src/tasks/bazel_packages.ts
./packages/kbn-repo-packages/package-map.json
./packages/kbn-ts-projects/config-paths.json
./packages/kbn-ui-shared-deps-npm/BUILD.bazel
./packages/kbn-ui-shared-deps-src/BUILD.bazel
./src/dev/build/tasks/build_packages_task.ts
./src/platform/packages/private/kbn-repo-packages/jest.config.js
./src/platform/packages/private/kbn-repo-packages/package-map.json
./src/platform/packages/private/kbn-ui-shared-deps-src/BUILD.bazel
./src/platform/packages/shared/kbn-cbor/jest.config.js
./src/platform/packages/shared/kbn-repo-info/jest.config.js
./src/platform/packages/shared/kbn-rison/jest.config.js
./src/platform/packages/shared/kbn-utils/jest.config.js
./tsconfig.base.json
./yarn.lock
.github/CODEOWNERS
```
</details><details >
<summary>Updated relative paths</summary>
```
src/platform/packages/private/kbn-repo-packages/jest.config.js:12
src/platform/packages/private/kbn-repo-packages/tsconfig.json:2
src/platform/packages/private/kbn-ui-shared-deps-npm/tsconfig.json:2
src/platform/packages/private/kbn-ui-shared-deps-src/tsconfig.json:2
src/platform/packages/shared/kbn-cbor/jest.config.js:12
src/platform/packages/shared/kbn-cbor/tsconfig.json:12
src/platform/packages/shared/kbn-cbor/tsconfig.json:2
src/platform/packages/shared/kbn-repo-info/jest.config.js:12
src/platform/packages/shared/kbn-repo-info/tsconfig.json:2
src/platform/packages/shared/kbn-rison/jest.config.js:12
src/platform/packages/shared/kbn-rison/tsconfig.json:2
src/platform/packages/shared/kbn-ui-theme/tsconfig.json:2
src/platform/packages/shared/kbn-utility-types-jest/tsconfig.json:2
src/platform/packages/shared/kbn-utils/jest.config.js:12
src/platform/packages/shared/kbn-utils/tsconfig.json:2
```
</details>
---------
Co-authored-by: Alex Szabo <alex.szabo@elastic.co>
Co-authored-by: Jonathan Budzenski <jon@elastic.co>
Co-authored-by: Michael Dokolin <mikhail.dokolin@elastic.co>
## Summary
**Reviewers: Please test the code paths affected by this PR. See the
"Risks" section below.**
Part of work for enabling "high contrast mode" in Kibana. See
https://github.com/elastic/kibana/issues/176219.
**Background:**
Kibana will soon have a user profile setting to allow users to enable
"high contrast mode." This setting will activate a flag with
`<EuiProvider>` that causes EUI components to render with higher
contrast visual elements. Consumer plugins and packages need to be
updated selected places where `<EuiProvider>` is wrapped, to pass the
`UserProfileService` service dependency from the CoreStart contract.
**NOTE:** **EUI currently does not yet support the high-contrast mode
flag**, but support for that is expected to come in around 2 weeks.
These first PRs are simply preparing the code by wiring up the
`UserProvideService`.
### Checklist
Check the PR satisfies following conditions.
Reviewers should verify this PR satisfies this list as well.
- [X] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios
- [X] The PR description includes the appropriate Release Notes section,
and the correct `release_note:*` label is applied per the
[guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
### Risks
Does this PR introduce any risks? For example, consider risks like hard
to test bugs, performance regression, potential of data loss.
Describe the risk, its severity, and mitigation for each identified
risk. Invite stakeholders and evaluate how to proceed before merging.
- [ ] [medium/high] The implementor of this change did not manually test
the affected code paths and relied on type-checking and functional tests
to drive the changes. Code owners for this PR need to manually test the
affected code paths.
- [ ] [medium] The `UserProfileService` dependency comes from the
CoreStart contract. If acquiring the service causes synchronous code to
become asynchronous, check for race conditions or errors in rendering
React components. Code owners for this PR need to manually test the
affected code paths.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## 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>
## Summary
This PR introduces the first internal version of the new theme
`Borealis` and ensures that:
- themes can be switched between "Amsterdam" and "Borealis"
- theme-specific Sass files are available and can be loaded with
`KBN_OPTIMIZER_THEMES=experimental`
- legacy JSON variable usage accounts for both themes
- static template styles account for both themes
## Running locally
```yml
// kibana.dev.yml or kibana.yml
uiSettings.experimental.themeSwitcherEnabled: true
```
Start kibana
```
KBN_OPTIMIZER_THEMES='v8light,v8dark,borealislight,borealisdark' yarn start
or
KBN_OPTIMIZER_THEMES=experimental yarn start
```
### Checklist
- [x] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios
- [ ] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed
---------
Co-authored-by: Tomasz Kajtoch <tomasz.kajtoch@elastic.co>
Closes https://github.com/elastic/kibana/issues/199361
While investigating, I found that fetching DOM element with id
`app-fixed-viewport` is a common pattern. I created the hook
`useAppFixedViewport` to consolidate this logic into a single location.
The hook only performs the DOM look-up on first render and then avoids
the DOM look-up on each additional render.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
This PR adds basic support for theme switching to test experimental
themes internally. It defines a new `theme:name` setting which is
read-only (and thus hidden) by default, and needs
`uiSettings.experimental.themeSwitcherEnabled: true` config setting to
become visible. The implementation and the way the theme switcher
feature is enabled will likely change in the upcoming weeks when we iron
out the details, but the way it works right now is sufficient for
testing and that's what the immediate goal is.
Please note this PR includes mostly setup work, and no additional themes
have been added here. To make reviewing slightly easier, these will be
added separately.
The feature and settings should be undocumented for the time being and
disabled by default.
---
As you might notice, there's a new setting added despite already having
`theme:version`. We decided to introduce a new setting instead of
resurrecting an existing one for better naming and flexibility and to
reduce the risk of breaking things that might still use the old setting
value (hardcoded to `v8` at the moment). The current plan is to remove
`theme:version` in 9.0.
The theme_loader got refactored to only bundle active themes coming from
`KBN_OPTIMIZER_THEMES` (defaulting to `v8light` and `v8dark`) instead of
`ALL_THEMES` that would significantly increase bundle sizes even when
the experimental themes were not enabled. Considering there's a SASS to
CSS-in-JS migration happening right now, we don't need to worry about
Kibana bundles growing in size when a new theme is officially added.
### Checklist
Delete any items that are not applicable to this PR.
- [x] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios
### For maintainers
- [ ] This was checked for breaking API changes and was [labeled
appropriately](https://www.elastic.co/guide/en/kibana/master/contributing.html#_add_your_labels)
- [ ] This will appear in the **Release Notes** and follow the
[guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Clint Andrew Hall <clint.hall@elastic.co>
Co-authored-by: Rudolf Meijering <skaapgif@gmail.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: Tiago Costa <tiago.costa@elastic.co>
## Summary
Trying #194082 again, this time wholly deleting
`kbn-ui-shared-deps-npm.v8.light/dark.css` as well 🤞
Original PR description:
> These files no longer contain any meaningful CSS used within Kibana as
of EUI's completed Emotion migration, and can be safely removed. EUI
will shortly no longer distribute these static `.css` files (although
`.scss` src files will still remain exported for the near future).
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Closes https://github.com/elastic/kibana/issues/185601
## Summary
Using non-compliant algorithms with Node Cryptos createHash function
will cause failures when running Kibana in FIPS mode.
We want to discourage usages of such algorithms.
---------
Co-authored-by: Sid <siddharthmantri1@gmail.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
At the moment, our package generator creates all packages with the type
`shared-common`. This means that we cannot enforce boundaries between
server-side-only code and the browser, and vice-versa.
- [x] I started fixing `packages/core/*`
- [x] It took me to fixing `src/core/` type to be identified by the
`plugin` pattern (`public` and `server` directories) vs. a package
(either common, or single-scoped)
- [x] Unsurprisingly, this extended to packages importing core packages
hitting the boundaries eslint rules. And other packages importing the
latter.
- [x] Also a bunch of `common` logic that shouldn't be so _common_ 🙃
### For maintainers
- [x] This was checked for breaking API changes and was [labeled
appropriately](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Fix https://github.com/elastic/kibana/issues/54376
Fix https://github.com/elastic/kibana/issues/127733
- get rid of the `InjectedMetadata.vars` and `getInjectedVar` deprecated
"API"
- Add `apmConfig` as an explicit `InjectedMetadata` property instead of
passing it via `vars`
- Inject the apm config from the `rendering` service instead of
`httpResource`, as it's just how it should be and how all other things
get injected.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Update i18n tools after the main packages upgrade. This upgrade makes
use of formatJS tooling instead of fully implementing the parsers
ourselves. It also changes our custom AST parsing from babel to the
typescript compiler.
- [x] i18n exrtract
- [x] i18n check
- [x] i18n integrate
- [x] add test cases for formatjs runner
- [x] Make sure all CLI flags are handled properly
- [x] Update tooling readme
Closes https://github.com/elastic/kibana/issues/180616
Closes https://github.com/elastic/kibana/issues/187703
### Note to reviewers
Teams outside operations and core are probably requested to review
because the `i18n_check` fixed malformed i18n messages in your plugins.
Please check and approve :elasticheart:
## Summary
fix https://github.com/elastic/kibana/issues/187570
The problem was that when the system/browser was in dark mode, the
default text color became white, but the background was forced to a
specific bright color, so the text became unreadable. A quick fix is to
also force the text color (I used EUI text colors)
<img width="858" alt="Screenshot 2024-07-05 at 12 44 11"
src="9ccefc04-60f6-46e3-a649-4e47cad043ac">
## Summary
Prep work for React@18 bump
tl;dr In React@18 `React.FC` doesn't contain `children` anymore, so in
order to make the bump easier I have decided to split the effort in
multiple faces and hopefully this will make it easier for everyone
This PR focuses only on adding explicit `children` declaration either by
using `React.PropsWithChildren` type or by adding `children:
React.ReactNode` to the existing props types
https://github.com/DefinitelyTyped/DefinitelyTyped/issues/46691
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Sergi Massaneda <sergi.massaneda@gmail.com>
Co-authored-by: Marco Vettorello <marco.vettorello@elastic.co>
Co-authored-by: James Gowdy <jgowdy@elastic.co>
## Summary
Part of https://github.com/elastic/kibana/issues/174578
Adapt Core's `userSettings` service to leverage Core's `userProfile`
service instead of the `security` plugin
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Part of https://github.com/elastic/kibana/issues/72880
- Generate translation files for all locales (including all internal
plugins) during the CDN asset generation task
- Adapt the `rendering` service to use the translation files from the
CDN if configured/enabled
### How to test
Connect to the serverless project that was created for the PR, and
confirm the translation file is being loaded from the CDN
<img width="907" alt="Screenshot 2024-04-25 at 15 55 23"
src="5a6d9110-2e92-41e5-b066-e792e0015134">
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Fix https://github.com/elastic/kibana/issues/83409
Use a permanent cache (`public, max-age=365d, immutable`) for
translation files when in production (`dist`), similar to what we're
doing for static assets.
Translation files cache busting is a little tricky, because it doesn't
only depend on the version (enabling or disabling a custom plugin can
change the translations while not changing the build hash), so we're
using a custom hash generated from the content of the current
translation file (which was already used to generate the `etag` header
previously).
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Partially addresses https://github.com/elastic/kibana-team/issues/805
Follows https://github.com/elastic/kibana/pull/180331
These changes come up from searching in the code and finding where
certain kinds of deprecated AppEx-SharedUX modules are imported.
**Reviewers: Please interact with critical paths through the UI
components touched in this PR, ESPECIALLY in terms of testing dark mode
and i18n.**
This focuses on code within Kibana Core.
<img width="1196" alt="image"
src="7f8d3707-94f0-4746-8dd5-dd858ce027f9">
Note: this also makes inclusion of `i18n` and `analytics` dependencies
consistent. Analytics is an optional dependency for the SharedUX
modules, which wrap `KibanaErrorBoundaryProvider` and is designed to
capture telemetry about errors that are caught in the error boundary.
### Checklist
Delete any items that are not applicable to this PR.
- [x] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios
- [ ] This renders correctly on smaller devices using a responsive
layout. (You can test this [in your
browser](https://www.browserstack.com/guide/responsive-testing-on-local-server))
- [ ] This was checked for [cross-browser
compatibility](https://www.elastic.co/support/matrix#matrix_browsers)
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Fix https://github.com/elastic/kibana/issues/89340
Implements a third option, `system`, for the `theme:darkMode`
uiSettings, which will follow the system's theme preference (light/dark)
when Kibana loads.
82078697-8bf5-41df-add1-4ecfed6e1dea
**Note: system theme refresh still requires the user to reload Kibana -
please see the next section for the reasons if you're interested**
## How theming works in Kibana, again?
This is an excellent question, thanks for asking. And the answer is,
"well, it's complicated".
We have multiples sources of "themed" styles in Kibana, ordered from
"best" to "worse":
#### 1. the EUI/JSS Theming
It was initially implemented in
https://github.com/elastic/kibana/pull/117368. All react applications
and react mountpoints are supposed to be wrapped by a
`KibanaThemeProvider` that bridges core's `theme$` values to the
`EuiProvider`.
477505a2dd/packages/core/theme/core-theme-browser-internal/src/core_theme_provider.tsx (L11)
This one was already dynamic and just works perfectly. If
`core.theme.theme$` changes, the new values is received by the theme
provider, which automatically changes the styles accordingly, creating
this sexy "it just works" effect:
f3e61ca7-f3ed-4c37-aa46-76ee68c1a628
If everything theme-related was using this approach, dynamic theme
reload would have been possible. However, Kibana has a lot of legacy, so
as you can imagine, it wasn't that easy.
So, **don't get false hopes** (as I did when I tried it...) from this
video. Dynamic theme swap **could not** be implemented in this PR. And
the reasons are just below.
#### 2. Per-theme css files
6443b57164/packages/core/rendering/core-rendering-server-internal/src/render_utils.ts (L40-L54)
We have a bunch of dark/light variations of some css files that are
computed in the rendering service, server-side, to be injected into the
page template.
Of course, this doesn't play well with dynamic theming, given the UI
then doesn't know which css should be swapped, and which one should be
added instead.
However, porting the responsibilities of which theme css files to load
to the browser was achievable, and done in this PR. core's browser-side
`theme` provider now receives the list of theme files for both light and
dark theme (via the injected metadata), and inject them in the document
(instead of having them pre-injected in the page template by the
rendering service server-side).
So this one wasn't a blocker for dynamic theme reload.
#### 3. Plugin styles
This is where the problems start.
Plugins can ship their own styles too, by importing them from components
or from their entrypoint.
E.g this component
f1dc1e1869/src/plugins/controls/public/control_group/component/control_group_component.tsx (L9)
importing this file:
bafb23580b/src/plugins/controls/public/control_group/control_group.scss (L107-L110)
Which relies on a theme variable, `$euiFormBackgroundColor`
So how does it works under the hood? How is that
`$euiFormBackgroundColor` variable interpolated? Using which theme?
Well, technically, how the styles are effectively loaded differs
slightly between dev and production (different webpack loaders/config),
but in both cases, it depends on the `__kbnThemeTag__` variable that is
injected to the global scope by the `bootstrap.js` script.
This `__kbnThemeTag__` tag (apparently) **can** be modified after page
load. However it doesn't magically reload everything, so styles already
loaded for one theme will not reload. If a component and its imported
styles were already compiled / injected, then they won't reload
As a short video is better than 3 blocks of text, just see:
3087ffd6-80d8-42bf-ab17-691ec408ea6f
That was the first blocker for supporting "dynamic" reloads of the
system theme.
#### 4. Static inline styles
Last but not least, we have some static style injected in the template,
that also depend on the current theme.
6443b57164/packages/core/rendering/core-rendering-server-internal/src/views/styles.tsx (L52-L54)
Of course this plays very badly with dynamic theming. And worth noting,
those styles are used by the "Loading Elastic" screen, where Core (and
therefore Core's theming service) isn't loaded yet, which made the
things even more complicated.
This was the second blocker for supporting "dynamic" reloads of the
system theme.
#### 5. `euiThemeVars`
Actually TIL (not that I was asking for it)
We're exposing the EUI theme variable via the `euiThemeVars` of the
`@kbn/ui-theme` package:
E.g.
c7e785383a/src/plugins/chart_expressions/expression_metric/public/components/metric_vis.tsx (L41)c7e785383a/src/plugins/chart_expressions/expression_metric/public/components/metric_vis.tsx (L50)
So I did my best, and made it that this export was a proxy, and that
Core's theme service was dynamically swapping the target of the proxy
depending on the system's theme...
b0a0017811/packages/kbn-ui-theme/src/theme.ts (L30-L42)
Unfortunately it doesn't fully work for dynamic system theme switch,
given modules/code can keep references of the property directly (e.g.
the snippet a few lines on top), and there's nothing to dynamically
reload components when the proxy changes.
So yet another blocker for dynamic theme switch.
## Release Notes
Add a new option, `system`, to the `theme:darkMode` Kibana advanced
setting, that can be used to have Kibana's theme follow the system's
(light or dark)
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Part of https://github.com/elastic/kibana/issues/144276
- Introduce the concept of browser-side logging configuration, via a
`logging.browser` config prefix
- Allow to configure the log level for the root browser logger via
`logging.browser.root.level`
- Set the default level to `info` for both dev and production mode
(consistent with server-side logging)
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Follow up of [first CDN
PR](https://github.com/elastic/kibana/pull/169408). Primary focus is
replacing our build nr with SHA that allows cache busting and maintains
anti-collision properties.
## How to test
Start Kibana as usual navigating around the app with the network tab
open in your browser of choice. Keep an eye out for any asset loading
errors. It's tricky to test every possible asset since there are many
permutations, but generally navigating around Kibana should work exactly
as it did before regarding loading bundles and assets.
## Notes
* did a high-level audit of usages of `buildNum` in `packages`, `src`
and `x-pack` adding comments where appropriate.
* In non-distributable builds (like dev) static asset paths will be
prefixed with `XXXXXXXXXXXX` instead of Node's `Number.MAX_SAFE_INTEGER`
* Added some validation to ensure the CDN url is of the expected form:
nothing trailing the pathname
### Checklist
Delete any items that are not applicable to this PR.
- [x] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios
### Risk Matrix
| Risk | Probability | Severity | Mitigation/Notes |
|---------------------------|-------------|----------|-------------------------|
| We break some first or third party dependencies on existing asset
routes | Med | High | Attempting to mitgate by serving static assets
from both old and new paths where paths have updated to include the
build SHA. Additioanlly: it is very bad practice to rely on the values
of the static paths, but someone might be |
| Cache-busting is more aggressive | High | Low | Unlikely to be a big
problem, but we are not scoping more static assets to a SHA and so every
new Kibana release will require clients to, for example, download fonts
again. |
### For maintainers
- [ ] This was checked for breaking API changes and was [labeled
appropriately](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Part of https://github.com/elastic/kibana/issues/170421
### 1. Introduce the `http.staticAssets` service
Which can be used to generate hrefs to Kibana's static assets in a
CDN-friendly way (based on the CDN url if defined in the config, and the
Kibana's basePath otherwise)
The service is exposed both on the browser and server-side.
For now a single API is exposed: `getPluginAssetHref`
```ts
// returns "/plugins/{pluginId}/assets/some_folder/asset.png" when CDN isn't configured
core.http.statisAssets.getPluginAssetHref('some_folder/asset.png');
```
### 2. Plug it on some of the `home` plugin assets
Adapt the sample data sets and tutorial schemas to use the service for
links to the associated assets
## How to test
#### 1. Edit`/etc/hosts`
add a line `127.0.0.1 local.cdn`
#### 2. Edit `kibana.yaml`
Add `server.cdn.url: "http://local.cdn:5601"`
#### 3. Boot kibana and navigate to sample data set installation
(if started in dev mode, use `--no-base-path`)
Confirm that the sample data set presentation images are pointing to the
CDN url and properly displayed:
<img width="1565" alt="Screenshot 2023-11-13 at 09 28 51"
src="23a887af-00cb-400c-9ab1-511ba463495f">
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Part of https://github.com/elastic/kibana-team/issues/646
Depends on https://github.com/elastic/kibana/pull/169324
Implements telemetry for fatal errors caught by KibanaErrorBoundary in:
-
`packages/core/application/core-application-browser-internal/src/ui/app_router.tsx`
- `packages/kbn-shared-ux-utility/src/with_suspense.tsx` [*]
- `packages/react/kibana_context/render/render_provider.tsx` [*]
-
`src/plugins/management/public/components/management_app/management_router.tsx`
-
`x-pack/plugins/observability_shared/public/components/page_template/page_template.tsx`
- `x-pack/plugins/security_solution/public/app/app.tsx`
[*] The changes made to these allowed the `analytics` dependency to be
provided optionally, to avoid a breaking API change for maintainers.
## Logging screenshot
You can trigger a fatal error in the new error boundary component in
most places in Kibana by adding a TypeError to a React component:
`<p>{breakHere()}</p>`
<img width="1586" alt="fatal error telemetry console log"
src="97f973ac-bb25-41f2-bfe2-547a23f2f450">
## Telemetry work info
Dashboard:
<img width="1382" alt="image"
src="4fe5353a-61ba-405a-ac18-0dd6a044c182">
Discover:
<img width="1331" alt="image"
src="2161b552-c441-4b7c-adef-25896147c08a">
### Checklist
- [x] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
### Summary
Fix https://github.com/elastic/kibana/issues/166688
Implements dynamic contract resolving for plugins, allowing to retrieve
contracts after their respective lifecycle is completed, and therefore
working around cyclic dependencies.
In term of workflow execution, we're basically going from
<img width="842" alt="Screenshot 2023-09-27 at 08 09 27"
src="251637d1-ec97-4071-a445-2f59512ce187">
to:
<img width="1092" alt="Screenshot 2023-09-27 at 08 09 32"
src="de466cda-7e43-4fd3-81ec-4339d05d279d">
### API
This functionality is exposed by the now publicly exposed `plugins`
service contracts:
```ts
setup(core) {
core.plugins.onSetup<{pluginA: SetupContractA, pluginB: SetupContractA}>('pluginA', 'pluginB')
.then(({ pluginA, pluginB }) => {
if(pluginA.found && pluginB.found) {
// do something with pluginA.contract and pluginB.contract
}
});
}
```
```ts
start(core) {
core.plugins.onStart<{pluginA: StartContractA, pluginB: StartContractA}>('pluginA', 'pluginB')
.then(({ pluginA, pluginB }) => {
if(pluginA.found && pluginB.found) {
// do something with pluginA.contract and pluginB.contract
}
});
}
```
**remark:** the `setup` contract exposed both `onSetup` and `onStart`,
while the `start` contract only exposed `onStart`. The intent is to
avoid fully disrupting the concept of lifecycle stages.
### Guardrails
To prevent developer from abusing this new API, or at least to add some
visibility on its adoption, plugins can only perforn dynamic contract
resolving against dependencies explicitly defined in their manifest:
- any required dependencies (*existing concept*)
- any optional dependencies (*existing concept*)
- any runtime dependencies (**new concept**)
Runtime dependencies must be specified using the new
`runtimePluginDependencies` field of a plugin's manifest.
```json
{
"type": "plugin",
"id": "@kbn/some-id",
"owner": "@elastic/kibana-core",
"plugin": {
"id": "some-id",
"...": "...",
"runtimePluginDependencies" : ["someOtherPluginId"]
}
}
```
Using the contract resolving API will throw at call time when trying to
resolve the contract for an undeclared dependency.
E.g this would throw at invocation time (not returning a rejected
promise - throw).
```ts
setup(core) {
core.plugins.onSetup<{undeclaredDependency: SomeContract}>('undeclaredDependency');
}
```
The reasoning behind throwing is that these errors should only occur
during the development process, and an hard fail is way more visible
than a promise rejection that should be more easily shallowed.
### Code reviews
This PR defines @elastic/kibana-core as codeowner of all `kibana.jsonc`
files in the `src/plugins` and `x-pack/plugins` directories, so that a
code review will be triggered whenever anyone changes something in any
manifest. The intent is to be able to monitor new usages of the feature,
via the addition of entries in the `runtimePluginDependencies` option of
the manifest.
### Remarks
Exposing this API, and therefore making possible cyclic dependencies
between plugins, opens the door to other questions.
For instance, cross-plugin type imports are not technically possible at
the moment, given that plugins are referencing each others via TS refs,
and refs forbid cyclic dependencies. Which means that to leverage this
to address cyclic dependency issues, the public types of **at least one
of the two** plugins will have to be extracted to a shared place (likely
a package).
Resolving, or trying to improve the developer experience around this
issue, is absolutely out of scope of the current PR (and the issue it
addresses).
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
We recently got problems because some index creation settings are
rejected by stateless ES, causing the whole system to fail and Kibana to
terminate.
We can't really use feature flags for this, given:
1. it doesn't really make sense to use manual flags for something that
strictly depend on one of our dependency's capabilities
2. we're mixing the concept of "serverless" offering and "serverless"
build. Atm we sometimes run "serverless" Kibana against traditional ES,
meaning that the "serverless" info **cannot** be used to determine if
we're connected against a default or serverless version of ES.
This was something that was agreed a few weeks back, but never acted
upon.
## Introducing ES capabilities
This PR introduces the concept of elasticsearch "capabilities".
Those capabilities are built exclusively from info coming from the ES
cluster (and not by some config flag).
This first implementation simply exposes a `serverless` flag, that is
populated depending on the `build_flavor` field of the `info` API (`/`
endpoint).
The end goal would be to expose a real capabilities (e.g "what is
supported") list instead. But ideally this would be provided by some ES
API and not by us guessing what is supported depending on the build
flavor, so for now, just exposing whether we're connected to a default
of serverless ES will suffice.
### Using it to adapt some API calls during SO migration
This PR also adapts the `createIndex` and `cloneIndex` migration action
to use this information and change their request against ES accordingly
(removing some index creation parameters that are not supported).
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
> Pre-req for https://github.com/elastic/kibana/issues/56406
## Summary
We've had a long-standing problem in Kibana around our use of React
context, particularly with EUI and i18n. There hasn't existed an
idempotent context structure, and that has lead to a lot of unexpected
results, (e.g. missing translations, inconsistent dark mode, excess
context providers, etc).
The biggest change coming from this PR is knowing exactly which provider
to use in a particular use case. This means, for example,
`ReactDOM.render` calls won't be missing `i18n` or `theme` due to a
missing context. It also allows consumers to use `darkMode` without
having to read the `uiSetting` themselves, instead allowing the context
to do it for them.
We also haven't been honoring the intended [`EuiProvider`
API](https://eui.elastic.co/#/utilities/provider#theming-and-global-styles)...
in some cases we've been creating and re-creating the Emotion caches,
often by copy/paste of the cache code. We've also been nesting
`EuiThemeProvider` contexts unnecessarily-- thinking we need to render a
theme provider in an isolated component-- which renders an additional
`span` element into the DOM.
This PR attempts to address this inconsistency by creating a set of
context providers divided by use case:
### `KibanaRootContextProvider`
A root context provider for Kibana. This is the top level context
provider that wraps the entire application. It is responsible for
initializing all of the other contexts and providing them to the
application. It's provided as a package for specific use cases, (e.g.
the `RenderingService`, cases where we replace the entire page content,
Storybook, testing, etc), but not intended for plugins.
### `KibanaRenderContextProvider`
A render context provider for Kibana. This context is designed to be
used with ad-hoc renders of React components, (usually with
`ReactDOM.render`).
### `KibanaThemeContextProvider`
A theme context provider for Kibana. A corollary to EUI's
`EuiThemeProvider`, it uses Kibana services to ensure the EUI Theme is
customized correctly.
### (deprecated) `KibanaStyledComponentsThemeProvider`
A styled components theme provider for Kibana. This package is supplied
for compatibility with legacy code, but should not be used in new code.
## Deprecation strategy
This PR does *not* change any use of context by consumers. It maps the
existing contexts in `kibanaReact` to the new contexts, (along with the
loose API). This means that we won't have completely fixed all of our
dark mode issues yet. But this is necessary to keep this PR focused on
the change, rather than drawing in a lot of teams to review individual
uses.
We should, however, see an immediate performance improvement in the UI
from the reduction in `EuiProvider` calls.
## Open questions
- [ ] Does it make sense to expose a `useTheme` hook from
`@kbn/react-kibana-context-theme` to replace `useEuiTheme`?
## Next steps
- [ ] Update deprecated uses to new contexts.
- [ ] Audit and update calls to `ReactDOM.render`.
- [ ] Add ESLint rule to warn for use of EUI contexts.
- [ ] Delete code from `kibanaReact`.
## Summary
When turning on `server.restrictInternalApis` a number of issues
surfaced due to defaulting to internal resulting in `400`s for:
* HTTP resources
* Static assets via `registerStaticDir`
* Use of `res.render(Html|Js|Css)` outside of HTTP resources
This PR:
* defaults our HTTP resources service to register routes by default
`public`, same for static dirs.
* Did an audit of all renderX usages, if outside of HTTP resources I
added an explicit `access: public`
* ...what else?
### Set `access: 'public'` for known set of "system" routes
Method | Path | Comment
-- | -- | --
GET | /api/status
GET | /api/stats
GET | /translations/{locale}.json
GET | /api/fleet/agent_policies
GET | /api/task_manager/_background_task_utilization
GET | /internal/task_manager/_background_task_utilization
GET | /internal/detection_engine/health/_cluster
POST | /internal/detection_engine/health/_cluster
GET | /internal/detection_engine/health/_space
POST | /internal/detection_engine/health/_space
POST | /internal/detection_engine/health/_rule
POST | /internal/detection_engine/health/_setup
GET | /bootstrap.js
GET | /bootstrap-anonymous.js
GET | \*\*/bundles/\* | Core's routes for serving JS & CSS bundles
## How to test
Run this PR with `kibana.dev.yml` containing
`server.restrictInternalApis: true` and navigate around Kibana UI
checking that there are no `400`s in the network resources tab due to
access restrictions.
## Notes
* Either left a comment about why `access` was set public or a simple
unit test to check that we are setting access for a given route
## To do
- [x] Manually test Kibana
- [x] Manually test with `interactiveSetup` plugin
- [ ] Add integration and e2e test (will do in a follow up PR)
Related: https://github.com/elastic/kibana/pull/162149
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Follow up to https://github.com/elastic/kibana/pull/161592
Some remaining EUI components that are still in Sass unfortunately need
to respect EUI's global CSS utilities (e.g. `.eui-yScroll`,
`.eui-textTruncate` - [full list
here](https://elastic.github.io/eui/#/utilities/css-utility-classes)).
Creating a separate utilities cache and insertion point should solve the
CSS order/specificity issues.
### Checklist
- [x] Confirm Emotion output order is expected in head (EUI globals, All
Emotion styles, Sass styles, then utilities last)
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Add a `buildFavor` property to `Env` (accessible from the plugin's
initializer context), Mimicking the idea of ES's `version.buildFlavor`
field.
Note: this is not supposed to be a replacement for feature flags, but
can be useful when wanting to toggle features based on actual
capabilities of our serverless product. Also, we already expose this
value through the configuration via the `serverless` context value, so
it now adds another way to access the information.
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Fixing calculated theme tags. An issue found was in the bootstrap
renderer when User Profile's Theme was set to 'Light' and Adv. Setting's
Theme was set to 'Dark'.
In my original PR, I had originally had the UserSettings > darkMode be a
string ('', 'light', 'dark'), but changed it to a boolean | undefined
and the conditional no longer worked.
This should fix a number of sporadic darkmode issues
## Summary
fixes https://github.com/elastic/kibana/issues/161441
fixes https://github.com/elastic/kibana/issues/161464
The recent `EuiButtonEmpty`/`EuiButtonIcon` Emotion conversions have
highlighted a CSS order/specificity flaw in Kibana compared to EUI - EUI
orders its Sass _after_ its Emotion styles (see
https://elastic.github.io/eui/#/), and Kibana orders Sass _before_
Emotion styles.
I'm not totally sure why Greg set up Kibana's style order the way he did
in https://github.com/elastic/kibana/pull/134919, but at this point, EUI
has enough of its baseline atom components converted to Emotion that
remaining components in Sass are all generally molecules or higher level
components that need to come after Emotion.
### QA
- [x] Test as many pages in Kibana as possible to ensure no visual
regressions 🤞
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Adds build date to `GET kbn:api/status` similar to ES. Example output
running locally:
```json
{
"name": "ES-DMVD5M3",
"uuid": "545ba70c-063e-449b-af21-6c8e7b30f77e",
"version": {
"number": "8.9.0",
"build_hash": "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX",
"build_number": 9007199254740991,
"build_snapshot": false,
"build_date": "2023-05-15T23:12:09.000Z"
},
...rest
}
```
### Checklist
- [x]
[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)
was added for features that require explanation or tutorials
- [x] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios
## Release Note
The status endpoint now returns the build date alongside other build
information.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
After changing the UserSettingService to calculate darkmode and return
`boolean | undefined` , the Rendering service `darkMode` logic needed to
be updated to work when a User chooses 'Light' which provides a 'false'
value to the Rendering service.
## Testing
For Space Setting:
1. Set Space Adv. Setting to darkMode: true
2. Set User Profile Setting to 'Light'
3. Observe that Light mode takes precedence
For Config setting:
1. Set User Profile Setting to 'Dark'
2. In `kibana.yml` set `uiSettings.overrides.theme:darkMode: false`
3. Observe that Light mode takes precedence
## Summary
This PR adds boilerplate code and a few initial end-to-end tests to
serverless plugins.
Note that the tests defined in this PR are not part of any CI run yet,
this will be done in a follow-up after this PR is merged.
### Details
The serverless test structure corresponds to what we have in
`x-pack/test` with API tests in `api_integration` and UI tests in
`functional`, each with their set of helper methods and sub-directories
for
- `common` functionality shared across serverless projects (core, shared
UX, ...)
- `observability` project specific functionality
- `search` project specific functionality
- `security` project specific functionality
The `shared` directory contains fixtures, services, ... that are shared
across `api_integration` abd `functional` tests.
```
x-pack/test_serverless/
├─ api_integration
│ ├─ services
│ ├─ test_suites
│ │ ├─ common
│ │ ├─ observability
│ │ ├─ search
│ │ ├─ security
├─ functional
│ ├─ page_objects
│ ├─ services
│ ├─ test_suites
│ │ ├─ common
│ │ ├─ observability
│ │ ├─ search
│ │ ├─ security
├─ shared
│ ├─ services
│ ├─ types
```
See also `x-pack/test_serverless/README.md`
### Run tests
Similar to how functional tests are run in `x-pack/test`, you can point
the functional tests server and test runner to config files in this
`x-pack/test_serverless` directory, e.g. from the `x-pack` directory
run:
```
node scripts/functional_tests_server.js --config test_serverless/api_integration/test_suites/common/config.ts
```
and
```
node scripts/functional_test_runner.js --config test_serverless/api_integration/test_suites/common/config.ts
```
### Additional changes
- The stateful `common_page` page object used the existence of the
global nav to determine `isChromeVisible` and `isChromeHidden`, which is
not working when the global nav is disabled. To solve this, a
`data-test-subj` that indicates the chrome visible state is added to the
Kibana app wrapper and is used for the checks.
- Add a few `data-test-subj` entries to the Observability overview page.
- Add optional `dataTestSubj` to the `Navigation` component and use that
for the serverless search nav.
- Add optional `titleDataTestSubj` to the `SolutionNav` component and
use it for the serverless security nav.
- Add a data-test-subj entry to the Search overview page.
## Summary
Allow user's to set their desired theme on their User Profile
## How to test
Login as a non-cloud user, navigate to User Profile:
<img width="1051" alt="Screenshot 2023-02-28 at 1 40 34 PM"
src="https://user-images.githubusercontent.com/21210601/221948512-a3e9b485-d3fa-4646-ae7d-63a68777cf19.png">
## Release Note
Users can now select their theme preference for Kibana in their User
Profile
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Michael Marcialis <michael.l.marcialis@gmail.com>
