Embeddable ViewMode is part of legacy embeddable architecture. This PR
removes Embeddable ViewMode and replaces its usage with
presentation-publishing ViewMode. presentation-publishing ViewMode is a
string literal type so an enum is no longer needed.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
Closes https://github.com/elastic/kibana/issues/212605
Here we are removing the clear button from the ES|QL control as clearing
will result in wrong charts. I also considered the reset but when there
is no changes should be hidden or disabled. This seems to me as a
smaller change and taken under consideration that dashboard already
allows resetting I think it is ok to remove it.
We can always reconsider if any user complains.
Although by removing the clearSelections from the control config removes
the button the `DefaultControlApi ` was marking it as required. So I had
to tweak a bit the types.
Update search control example with buttons to programmatically interact
with controls
<img width="800" alt="Screenshot 2025-02-27 at 8 41 05 AM"
src="https://github.com/user-attachments/assets/e936cdeb-ce51-4fca-a8bc-ec5d983e3155"
/>
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
PR cleans up presentation interface names for consistentency
* adds `$` suffix to all observables. For example, `dataLoading` =>
`dataLoading$`
* removes `Panel` naming convention from interface names since an api
may not be a panel, an api may be a dashboard. For example,
`PublisesPanelTitle` => `PublishesTitle`
#### Note to Reviewers
Pay special attention to any place where your application creates an
untyped API. In the example below, there is no typescript violation when
the parent returns `dataLoading` instead of `dataLoading$` since the
parent is not typed as `PublishesDataLoading`. Please check for
instances like these.
```
<ReactEmbeddableRenderer
getParentApi={() => {
dataLoading: new BehaviorSubject()
}}
/>
```
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Unifies the various `LibraryTransforms` interfaces, updates all by reference capable embeddables to use them in the same way, and migrates the clone functionality to use only serialized state.
## 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>
Part of https://github.com/elastic/kibana/issues/192005
Closes https://github.com/elastic/kibana/issues/176533
## Summary
This PR represents the first major cleanup task for the control group
embeddable refactor. The tasks included in this PR can be loosely
summarized as follows:
1. This PR removes the old, non-React version of controls
- Note that the new controls are still included under the
`react_controls` folder - I will address this in a follow up PR.
2. This PR removes **all** types associated with the old embeddable
system; i.e. any `*input*` or `*output*` types.
- As part of cleaning up these types, some of the types included in the
`public/react_controls` folder had to be moved to `common` to make them
available to server-side code.
- This resulted in an... unfortunate number of import changes 🫠 Hence
the rather large file change count. I took this opportunity to organize
the imports, too - so a significant chunk of these files are simply
import changes.
3. This PR removes the controls Storybook and all related mocks
- Since the controls storybooks have been broken for awhile, and since
we had plans to remove them but never got around to it, I just decided
to delete them as part of this PR and close
https://github.com/elastic/kibana/issues/176533 rather than spending
time to fix the types for non-operational stories
### Checklist
- [x] Any text added follows [EUI's writing
guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses
sentence case text and includes [i18n
support](https://github.com/elastic/kibana/blob/main/packages/kbn-i18n/README.md)
- [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#kibana-release-notes-process)
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Closes https://github.com/elastic/kibana/issues/189820
### Summary
This PR converts the `ControlGroupRenderer` to use the new control group
embeddable, which is built on the new React embeddable framework. With
this conversion, there should not be **any** changes in user-facing
behaviour - therefore, testing of this PR should be focused on ensuring
that no behaviour is changed and/or broken with this refactor.
**Notes to Solution Reviewers:**
- There should be minimal changes to your uses of `ControlGroupRenderer`
- our goal here was to keep the exposed API more-or-less consistent with
this refactor. Therefore, most changes are simply renames + changes of
imports.
- That being said, `updateInput` and `getInput$` are **very much** tied
to the old embeddable infrastructure - so while they will continue to
work for now, they have been deprecated in favour of adding
setters/getters for the parts of the control group state that you need
to update / respond to.
**Notes to Presentation Reviewer:**
- The bundle size was originally being increased by this PR, so I
decided to remove a bunch of the public exports that are no longer
necessary as a final cleanup - this resulted in changes to imports in a
few files, but it was worth doing in this PR IMO so that we didn't have
to increase the Controls bundle limit. Now, this PR shrinks the bundle
size 🎉
- I fixed a small bug with the default value of `showApplySelections` in
this PR - since it was a one-line change, if felt like overkill to
separate it out. See
https://github.com/elastic/kibana/pull/190561/files#r1733253015
### 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
### 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>
PR replaces legacy embeddable control group implementation with react
control group implementation in DashboardContainer.
#### background
Work originally done in https://github.com/elastic/kibana/pull/190273.
https://github.com/elastic/kibana/pull/190273 was reverted by
https://github.com/elastic/kibana/pull/191993 because of dashboard
performance degradation. It was determined that degradation was because
new react embeddable controls fixed a regression where dashboard panels
are loading before control filters are created. This regression was
introduced by https://github.com/elastic/kibana/pull/187509.
The work around is that this PR keeps the currently broken behavior in
main and loads panels before control filters are ready. The thinking is
that the migration would replace like for like and not introduce any
performance changes. Then, at a later time, the regression could be
resolved.
#### reviewing
These are the same changes from
https://github.com/elastic/kibana/pull/190273 minus some work to
introduce a current regression in main. A full re-review is not needed.
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: Hannah Mudge <hannah.wright@elastic.co>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
#190273 introduced a performance regression. Reverting to move metrics to baseline again and create some time to identify root cause.
Co-authored-by: Thomas Neirynck <thomas@elastic.co>
closes https://github.com/elastic/kibana/issues/191137,
https://github.com/elastic/kibana/issues/190988,
https://github.com/elastic/kibana/issues/191155
PR replaces legacy embeddable control group implementation with react
control group implementation in DashboardContainer.
### Test instructions
1. Open dashboard via dashboard application or portable dashboard
2. Mess around with controls. There should be no changes in behavior
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Hannah Mudge <Heenawter@users.noreply.github.com>
PR added `lastUsedDataViewId$` to `ControlGroupApi`.
`lastUsedDataViewId$` is implemented in `initializeControlsManager`.
PR also cleaned up typings by removing `DataControlEditorState`.
`DataControlEditorState` was a weird smooshing together of
DefaultDataControlState and stuff used by the editor. Instead of
`DataControlEditorState`, values used by the editor are just passed in
as top level keys.
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Move react_controls from examples plugin to controls plugin. This PR
does not effect user facing features since it does not effect the legacy
control group implementation or its usage. Future PRs will integrate the
new control group with dashboard and ControlGroupRenderer and then
remove the legacy control group implementation.
PR increases page load bundle size because of new action registration
and the control group react embeddable registration. This will be a
temporary increase as removing the legacy control group will remove the
legacy embeddable factory registration, which is larger then react
embeddable registration.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Hannah Mudge <Heenawter@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Fixes https://github.com/elastic/kibana/issues/189580
PR awaits until all control filters are ready and then applies
selections during reset.
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Closes https://github.com/elastic/kibana/issues/189407
## Summary
This PR adds an `order` attribute to the control factory so that the
ordering in the UI remains consistent - previously, the order was
determined by the order the factories were registered in (which is no
longer predictable now that the registration happens `async` - it's hard
to repro, but there were times where something delayed the options list
registration and it would appear at the end of my list). Adding and
sorting the UI based on the `order` of the factory removes this
uncertainty.
### 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
### 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)
## Summary
The range slider `value` was getting overwritten by the old value on
edit after the field name changed because we were passing in `value` as
part of the editor state manager - so, this resulted in the following
when editing a range slider with a defined `value` (for the sake of
clarity, let's say `value = [100, 200]`.
1. Change the field name to another number field (keeping it as a range
slider control) and save your changes
2. On save, the editor loops through the provided state manager key by
key and updates the control
3. The `fieldName` key is hit first because of the order of spread, so
this gets updated - which triggers the `fieldChangedSubscription` and
sets `value` to `undefined`
4. The `value` key gets hit afterward, which still has the old `[100,
200]` value because we don't clear up the dirty state - so, the editor
calls `value$.next([100, 200])`
5. The edited control now has the same selection as the old control
🔥
We should only add state to the editor state manager **that the editor
can change** - and since `value` is never changed via the editor,
removing this from the state manager fixes the above situation. I've
added a comment to hopefully clarify this.
### How to test
1. Create a range slider control and make a value change on it
2. Edit that control and pick a different data view and/or field - keep
it as a range slider control!
3. The value selected at step 1 **should be cleared**
### Before
https://github.com/user-attachments/assets/e6700538-deda-4196-8f52-c5446fa06518
### After
https://github.com/user-attachments/assets/be47fb2c-ecbf-4274-8beb-82a7e5462874
### 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)
While reviewing https://github.com/elastic/kibana/pull/188687, I noticed
that controls where still getting filtered by timeslider changes even
when chaining was disabled or the control was to the left of the
timeslider. This PR resolves this issue by only passing in timeslice
from `chaining$` instead of `controlGroupFetch$`.
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>
PR does the following
* Adds `untilInitialized` to `ControlGroupApi`.
* Control group example updated to not mount data table react embeddable
until control group is initialized (and all control group filters are
available)
* Updates `buildControl` to be async
* Updates all controls to `await` filters before returning
`buildControl`
* Updates control group to display loading indicator until all controls
loaded
* Moves control group react logic into `ControlGroup` component
* Implements `Apply` button
<img width="600" alt="Screenshot 2024-07-24 at 7 33 25 AM"
src="https://github.com/user-attachments/assets/4840c731-2287-4a12-aa9c-3d9c83d64d14">
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This PR fixes control editing so that, when the control type is changed,
extra state from the old type gets removed. Prior to this, controls were
keeping unrelated state - for example, switching from a range slider to
a search control would result in a search control with the "step"
property.
### 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
### 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)
Closes https://github.com/elastic/kibana/issues/187504
## Summary
This PR changes how control creation/editing is handled in the new
system by changing from a state manager to an explicit `initialState` +
`updateState` callback structure. Unfortunately, the `stateManager`
system really only works if we had inline creation for controls - since
we don't have that, the embeddable (and hence the `stateManager`)
doesn't exist until **after** the editor is saved. Therefore, especially
with respect to the custom options component, we had no way of knowing
what keys the `stateManager` should include when trying to create a new
control. The new system isn't quite as clean IMO, but it works better
for our current goals with this refactor. We can revisit the
`stateManager` idea once controls support inline editing 👍
This PR also fixes a few visual bugs, noted below.
### 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
- [x] 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))
### 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>
Closes https://github.com/elastic/kibana/issues/187382
## Summary
This PR separates out the previously memoized
`CompatibleControlTypesComponent` into a separate component that accepts
**props** for the fields that it is dependant on rather than relying on
the dependencies to the `useMemo` function. This is because, previously,
we had an extra dependency in the dependency array (`controlType`) that
was causing the memoized component to render too many times and it was
causing a weird bug where the old "disabled" menu item wasn't getting
unmounted properly.
| Before | After |
|--------|--------|
| 
| 
|
By switching to a component with explicit props, unnecessary
dependencies should hopefully be avoided in the future.
### 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)
## Summary
The primary goal of this PR is to clean up the styling of the
`ControlPanel` component for the new React control renderer.
Specifically, this fixes the following:
- I switched the inline Emotion styling to CSS classes instead
- I made it so that the timeslider control renders the drag handler in
edit mode and **doesn't** render the empty icon for the drag handler in
view mode
<p align="center"><img width="600px"
src="d5bf169b-2106-4f88-9698-f00162809d0a"/><p>
- I fixed the timeslider prepend so that it no longer wraps
<p align="center"><img width="500px"
src="7859d67b-1454-45b5-b7d8-7000086641a7"/><p>
- I moved the error component into the `EuiFormControlLayout` component,
which ensures that the drag handler is rendered for when a control has a
blocking error. I also fixed the styling for the error component:
<p align="center"><img width="600px"
src="13e0f041-8c51-494c-9079-323ed518c87b"/><p>
When I was working on these style changes, I noticed that the timeslider
control wasn't implementing `CanClearSelections` which meant that it no
longer had the clear selections action. This made me realize that this
interface should probably be part of the `DefaultControlApi` rather than
`DefaultDataControlApi` so, I moved it and added `clearSelections` to
the timeslider API.
<p align="center"><img width="600px"
src="47f7b648-bb2d-4158-b058-456bfdf5cdb5"/><p>
### Checklist
- [x] Any UI touched in this PR is usable by keyboard only (learn more
about [keyboard accessibility](https://webaim.org/techniques/keyboard/))
- [x] Any UI touched in this PR does not create any new axe failures
(run axe in browser:
[FF](https://addons.mozilla.org/en-US/firefox/addon/axe-devtools/),
[Chrome](https://chrome.google.com/webstore/detail/axe-web-accessibility-tes/lhdoppojpmngadmnindnejefpokejbdd?hl=en-US))
- [x] 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))
### 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>
Closes https://github.com/elastic/kibana/issues/184376
### Note for design review
index.scss file is just copy of
https://github.com/elastic/kibana/blob/main/src/plugins/controls/public/time_slider/components/index.scss.
We are migrating controls in the examples folder and then will migrate
these back into src folder once the migration is complete
### Changes
Changes to ControlGroupApi
* Implement timeslice$ API
* Implement autoApplySelections$
* Runtime state `autoApplySelections` is inverse of serialized state
`showApplySelections`
<img width="1000" alt="Screenshot 2024-06-11 at 12 56 45 PM"
src="dc27e3e3-6c25-4d5a-ab25-bfcc9bb38178">
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Hannah Mudge <hannah.wright@elastic.co>
Co-authored-by: Hannah Mudge <Heenawter@users.noreply.github.com>
PR updates initializeDataControl to handle error cases like DataView not
found and field not found.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Closes https://github.com/elastic/kibana/issues/184373
## Summary
This PR marks the first step of the control group migration to the new
React embeddable system. A few notes about this:
- In the new system, each individual control will no longer be an
"embeddable" - instead, we are creating a **new** control-specific
registry for all controls. This is **modelled** after the embeddable
registry, but it is locked down and much more controls-specific.
- Most of the work accomplished in this PR is hidden away in the
`examples` plugin - that way, user-facing code is not impacted. After
some discussion, we decided to do it this way because refactoring the
control group to work with both legacy and new controls (like we did for
the dashboard container) felt like a very large undertaking for minimal
benefit. Instead, all work will be contained in the example plugin
(including building out the existing control types with the new
framework) and we will do a final "swap" of the legacy control group
with the new React control group as part of
https://github.com/elastic/kibana/issues/174961
- This PR does **not** contain a fully functional control group
embeddable - instead, the main point of this PR is to introduce the
control registry and an example control. The current control group
embeddable is provided just to give the **bare minimum** of
functionality.
- In order to find the new Search control example, navigate to Developer
Examples > Controls > Register a new React control
- The example search control only works on text fields. See
https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl-match-query.html
and
https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl-simple-query-string-query.html
for information on the two search techniques.
### Checklist
- [x] Any text added follows [EUI's writing
guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses
sentence case text and includes [i18n
support](https://github.com/elastic/kibana/blob/main/packages/kbn-i18n/README.md)
- [x] This was checked for [cross-browser
compatibility](https://www.elastic.co/support/matrix#matrix_browsers)
### 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>
Aligns the Portable Dashboard renderer and the Control Group renderer to a new API structure using `useImperativeHandle` rather than the overcomplicated and mostly unused wrapper provider system.
## Summary
This PR adds the option to provide, custom props when calling
`openAddDataControlFlyout`. For example, users of the API may want
different placeholder than default for any new options list that is
added.
Currently, in security solution, we need a custom placeholder for newly
added controls. Hence, this PR. Please let me know if this is not the
best way to do this.
https://user-images.githubusercontent.com/7485038/232775198-a111d711-ffba-4d26-8c70-c2af08008e05.mov
Adds an "add" button that shows up to the right of the Control Group if
configured. Also adds a system for fetching settings from consumers, and
adds settings that can hide or show pieces of the Control editor flyout.
Fixes https://github.com/elastic/kibana/issues/149344
This PR migrates all plugins to packages automatically. It does this
using `node scripts/lint_packages` to automatically migrate
`kibana.json` files to `kibana.jsonc` files. By doing this automatically
we can simplify many build and testing procedures to only support
packages, and not both "packages" and "synthetic packages" (basically
pointers to plugins).
The majority of changes are in operations related code, so we'll be
having operations review this before marking it ready for review. The
vast majority of the code owners are simply pinged because we deleted
all `kibana.json` files and replaced them with `kibana.jsonc` files, so
we plan on leaving the PR ready-for-review for about 24 hours before
merging (after feature freeze), assuming we don't have any blockers
(especially from @elastic/kibana-core since there are a few core
specific changes, though the majority were handled in #149370).
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
This PR upgrades uuid into its latest version `9.0.0`.
The previous default used version `v4` was kept where it was previously
used and places using `v1` or `v5` are still using it.
In this latest version they removed the deep import feature and as we
are not using tree shaking it increased our bundles by a significant
size. As such, I've moved this dependency into the `ui-shared-deps-npm`
bundle.
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
