## 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
Added a search provider to return only visible indices and land in the
overview page once clicked or selected.
### No indices available
<img width="1046" alt="Screenshot 2024-01-24 at 2 48 58 PM"
src="82d5a997-2d0b-42e0-8818-2f4b83170230">
### Matched index shows up
<img width="920" alt="Screenshot 2024-01-24 at 2 42 13 PM"
src="59bd676c-f5c3-4b10-a1ae-cd8b4008c81e">
### Shows all matched index
<img width="1048" alt="Screenshot 2024-01-24 at 2 50 09 PM"
src="30877185-ac9c-4fe2-b859-d597dd3941b1">
### Checklist
Delete any items that are not applicable to this PR.
- [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)
- [ ]
[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
- [ ] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed
- [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))
- [ ] If a plugin configuration key changed, check if it needs to be
allowlisted in the cloud and added to the [docker
list](https://github.com/elastic/kibana/blob/main/src/dev/build/tasks/os_packages/docker_generator/resources/base/bin/kibana-docker)
- [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))
- [x] This was checked for [cross-browser
compatibility](https://www.elastic.co/support/matrix#matrix_browsers)
### Risk Matrix
Delete this section if it is not applicable to this PR.
Before closing this PR, invite QA, stakeholders, and other developers to
identify risks that should be tested prior to the change/feature
release.
When forming the risk matrix, consider some of the following examples
and how they may potentially impact the change:
| Risk | Probability | Severity | Mitigation/Notes |
|---------------------------|-------------|----------|-------------------------|
| Multiple Spaces—unexpected behavior in non-default Kibana Space.
| Low | High | Integration tests will verify that all features are still
supported in non-default Kibana Space and when user switches between
spaces. |
| Multiple nodes—Elasticsearch polling might have race conditions
when multiple Kibana nodes are polling for the same tasks. | High | Low
| Tasks are idempotent, so executing them multiple times will not result
in logical error, but will degrade performance. To test for this case we
add plenty of unit tests around this logic and document manual testing
procedure. |
| Code should gracefully handle cases when feature X or plugin Y are
disabled. | Medium | High | Unit tests will verify that any feature flag
or plugin combination still results in our service operational. |
| [See more potential risk
examples](https://github.com/elastic/kibana/blob/main/RISK_MATRIX.mdx) |
### 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: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Fix https://github.com/elastic/kibana/issues/146881
Introduce the concept of "capability path" to Core's capabilities API,
and rely on it to perform various performance optimization during
capabilities resolving.
### API Changes
#### CapabilitiesSetup.registerSwitcher
A new mandatory `capabilityPath` option was added to the API signature.
Plugins registering capability switchers must now define the path(s) of
capabilities the switcher will impact.
E.g a live example with the `ml` capabilities switcher that was only
mutating `ml.{something}` capabilities:
*Before:*
```ts
coreSetup.capabilities.registerSwitcher(getSwitcher(license$, logger, enabledFeatures));
```
*After:*
```ts
coreSetup.capabilities.registerSwitcher(getSwitcher(license$, logger, enabledFeatures), {
capabilityPath: 'ml.*',
});
```
#### CapabilitiesStart.resolveCapabilities
The `resolveCapabilities` was also changed accordingly, forcing API
consumers to specify the path(s) of capabilities they're planning to
access.
E.g for the `ml` plugin's capabilities resolving
*Before:*
```ts
const capabilities = await this.capabilities.resolveCapabilities(request);
return capabilities.ml as MlCapabilities;
```
*After:*
```ts
const capabilities = await this.capabilities.resolveCapabilities(request, {
capabilityPath: 'ml.*',
});
return capabilities.ml as MlCapabilities;
```
### Performance optimizations
Knowing which capability path(s) the switchers are impacting and which
capability path(s) the resolver wants to use allow us to optimize the
way we're chaining the resolvers during the `resolveCapabilities`
internal implementation:
#### 1. We only apply switchers that may impact the paths the resolver
requested
E.g when requesting the ml capabilities, we now only apply the `ml`,
`security` and `spaces` switchers.
#### 2. We can call non-intersecting switchers in parallel
Before, all switchers were executed in sequence. With these changes, we
now group non-intersecting switchers to resolve them in parallel.
E.g the `ml` (`ml.*`) and `fileUpload` (`fileUpload.*`) can be executed
and applied in parallel because they're not touching the same set of
capabilities.
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
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>
## Dearest Reviewers 👋
I've been working on this branch with @mistic and @tylersmalley and
we're really confident in these changes. Additionally, this changes code
in nearly every package in the repo so we don't plan to wait for reviews
to get in before merging this. If you'd like to have a concern
addressed, please feel free to leave a review, but assuming that nobody
raises a blocker in the next 24 hours we plan to merge this EOD pacific
tomorrow, 12/22.
We'll be paying close attention to any issues this causes after merging
and work on getting those fixed ASAP. 🚀
---
The operations team is not confident that we'll have the time to achieve
what we originally set out to accomplish by moving to Bazel with the
time and resources we have available. We have also bought ourselves some
headroom with improvements to babel-register, optimizer caching, and
typescript project structure.
In order to make sure we deliver packages as quickly as possible (many
teams really want them), with a usable and familiar developer
experience, this PR removes Bazel for building packages in favor of
using the same JIT transpilation we use for plugins.
Additionally, packages now use `kbn_references` (again, just copying the
dx from plugins to packages).
Because of the complex relationships between packages/plugins and in
order to prepare ourselves for automatic dependency detection tools we
plan to use in the future, this PR also introduces a "TS Project Linter"
which will validate that every tsconfig.json file meets a few
requirements:
1. the chain of base config files extended by each config includes
`tsconfig.base.json` and not `tsconfig.json`
1. the `include` config is used, and not `files`
2. the `exclude` config includes `target/**/*`
3. the `outDir` compiler option is specified as `target/types`
1. none of these compiler options are specified: `declaration`,
`declarationMap`, `emitDeclarationOnly`, `skipLibCheck`, `target`,
`paths`
4. all references to other packages/plugins use their pkg id, ie:
```js
// valid
{
"kbn_references": ["@kbn/core"]
}
// not valid
{
"kbn_references": [{ "path": "../../../src/core/tsconfig.json" }]
}
```
5. only packages/plugins which are imported somewhere in the ts code are
listed in `kbn_references`
This linter is not only validating all of the tsconfig.json files, but
it also will fix these config files to deal with just about any
violation that can be produced. Just run `node scripts/ts_project_linter
--fix` locally to apply these fixes, or let CI take care of
automatically fixing things and pushing the changes to your PR.
> **Example:** [`64e93e5`
(#146212)](64e93e5806)
When I merged main into my PR it included a change which removed the
`@kbn/core-injected-metadata-browser` package. After resolving the
conflicts I missed a few tsconfig files which included references to the
now removed package. The TS Project Linter identified that these
references were removed from the code and pushed a change to the PR to
remove them from the tsconfig.json files.
## No bazel? Does that mean no packages??
Nope! We're still doing packages but we're pretty sure now that we won't
be using Bazel to accomplish the 'distributed caching' and 'change-based
tasks' portions of the packages project.
This PR actually makes packages much easier to work with and will be
followed up with the bundling benefits described by the original
packages RFC. Then we'll work on documentation and advocacy for using
packages for any and all new code.
We're pretty confident that implementing distributed caching and
change-based tasks will be necessary in the future, but because of
recent improvements in the repo we think we can live without them for
**at least** a year.
## Wait, there are still BUILD.bazel files in the repo
Yes, there are still three webpack bundles which are built by Bazel: the
`@kbn/ui-shared-deps-npm` DLL, `@kbn/ui-shared-deps-src` externals, and
the `@kbn/monaco` workers. These three webpack bundles are still created
during bootstrap and remotely cached using bazel. The next phase of this
project is to figure out how to get the package bundling features
described in the RFC with the current optimizer, and we expect these
bundles to go away then. Until then any package that is used in those
three bundles still needs to have a BUILD.bazel file so that they can be
referenced by the remaining webpack builds.
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
* [build_ts_refs] improve caches, allow building a subset of projects
* cleanup project def script and update refs in type check script
* rename browser_bazel config to avoid kebab-case
* remove execInProjects() helper
* list references for tsconfig.types.json for api-extractor workload
* disable composite features of tsconfig.types.json for api-extractor
* set declaration: true to avoid weird debug error
* fix jest tests
Co-authored-by: spalger <spalger@users.noreply.github.com>
* Use Serializable from package
* Rename to align with core
* fix
* more replacements
* docssss
* fix
* Move it to @kbn/utility-types and remove core export
* buildy build
* tests
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
* add base config for all the TS projects
* all the project use new tsconfig.project.json
* compile test files in the high-level tsconfig.json
* fix TS error in maps plugin
* fix TS error in infra plugin
* exclude mote test and test until folders
* uptime. do not import test code within prod code
* expressions. do not import test code within prod code
* data: export mocks from high level folder
* task_manager: comply with es client typings
* infra: remove unused enzyme_helpers
* check_ts_project requires "include" key
* ts_check should handle parent configs
* all ts configs should extend base one
* exclude test folders from plugins
* update patterns to fix ts_check errors
* Apply suggestions from code review
Co-authored-by: Constance <constancecchen@users.noreply.github.com>
* uptime: MountWithReduxProvider to test helpers
Co-authored-by: Constance <constancecchen@users.noreply.github.com>
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
* first pass
* migrate more plugins
* migrate yet more plugins
* more oss plugins
* fix test file
* change Plugin signature on the client-side too
* fix test types
* migrate OSS client-side plugins
* migrate OSS client-side test plugins
* migrate xpack client-side plugins
* revert fix attempt on fleet plugin
* fix presentation start signature
* fix yet another signature
* add warnings for server-side async plugins in dev mode
* remove unused import
* fix isPromise
* Add client-side deprecations
* update migration examples
* update generated doc
* fix xpack unit tests
* nit
* (will be reverted) explicitly await for license to be ready in the auth hook
* Revert "(will be reverted) explicitly await for license to be ready in the auth hook"
This reverts commit fdf73feb
* restore await on on promise contracts
* Revert "(will be reverted) explicitly await for license to be ready in the auth hook"
This reverts commit fdf73feb
* Revert "restore await on on promise contracts"
This reverts commit c5f2fe51
* add delay before starting tests in FTR
* update deprecation ts doc
* add explicit contract for monitoring setup
* migrate monitoring plugin to sync
* change plugin timeout to 10sec
* use delay instead of silence
* add search syntax parsing logic
* fix ts types
* use type filter in providers
* move search syntax logic to the searchbar
* fix test plugin types
* fix test plugin types again
* use `onSearch` prop to disable internal component search
* add tag filter support
* add FTR tests
* move away from CI group 7
* fix unit tests
* add unit tests
* remove the API test suite
* Add icons to the SO results
* add test for unknown type / tag
* nits
* ignore case for the `type` filter
* Add syntax help text
* remove unused import
* hide icon for non-application results
* add tsdoc on query utils
* coerce known filter values to string
Co-authored-by: Ryan Keairns <contactryank@gmail.com>
Jest tests are currently organized into main configuration files (src/dev/jest/config.js and x-pack/dev-tools/jest/create_jest_config.js). Both of these are similar, but very slightly due to previously being in separate repositories. This change consolidates the scripts referenced in those configs and moves them to the `@kbn/test` project.
OSS contained an alias for `test_utils`. Those aliases have been removed in favor of importing these utilities from `@kbn/test/jest`
Blocker to #72569
Signed-off-by: Tyler Smalley <tyler.smalley@elastic.co>
* move last snapshot to inline
* move legacy files to legacy subfolder
* move request types out of legacy
* export Headers from http instead of elasticsearch
* renaming - first pass
* renaming - second pass
* fix core mocks
* adapt new calls
* update generated doc
* fix IT test mocks
* fix new usages
* add skeleton for global_search plugin
* base implementation of the server-side service
* add utils tests
* add server-side mocks
* move take_in_array to common folder
* implements base of client-side plugin
* add tests for server-side service
* fix server plugin tests
* implement `navigateToUrl` core API
* extract processResults for the client-side
* fetch server results from the client side
* factorize process_results
* fix plugin start params
* move things around
* move all server types to single file
* fix types imports
* add basic FTR tests
* add client-side service tests
* add tests for addNavigate
* add getDefaultPreference & tests
* use optional for RequestHandlerContext
* add registerRoutes test
* add base test for context
* resolve TODO
* common nits/doc
* common nits/doc on public
* update CODEOWNERS
* add import for declare statement
* add license check on the server-side
* add license check on the client-side
* eslint
* address some review comments
* use properly typed errors for obs
* add integration tests for the find endpoint
* fix unit tests
* use licensing start contract
* translate the error message
* fix eslint rule for test_utils
* fix test_utils imports
* remove NavigableGlobalSearchResult, use `application.navigateToUrl` instead.
* use coreProvider plugin in FTR tests
* nits
* fix service start params
* fix service start params, bis
* I really need to fix this typecheck oom error
* add README, update missing jsdoc
* nits on doc
