-
Notifications
You must be signed in to change notification settings - Fork 8.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Move core config service to kbn/config
package
#76874
Move core config service to kbn/config
package
#76874
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is WIP, and this PR is only the first step (it 'just' moves the config service code to a package, does not move schemas yet, nor allow consumers to easily create a configured config service), but
Before going any further, some important points and questions. The most important ones are probably:
- How to solve the
logging
module import from the now-in-packageconfig
service Move core config service tokbn/config
package #76874 (comment) - The effect on the generated doc to have this code moved into a package Move core config service to
kbn/config
package #76874 (comment) - The way we now expose the mocks / test utils from the package Move core config service to
kbn/config
package #76874 (comment) - Importing the
package.json
from theenv.ts
file / usingREPO_ROOT
breaks tests mocking thefs
package Move core config service tokbn/config
package #76874 (comment)
packages/kbn-config/README.md
Outdated
`@kbn/config-schema` is a TypeScript library inspired by Joi and designed to allow run-time validation of the | ||
Kibana configuration entries providing developers with a fully typed model of the validated data. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
need to add proper readme once this is finished.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This reference to @kbn/config-schema
is rather confusing. Isn't it? Let's remove it
packages/kbn-config/src/logging.ts
Outdated
export type LoggingConfigType = any; | ||
|
||
export type LogLevel = any; | ||
export type LogMeta = any; | ||
|
||
export interface LogRecord { | ||
timestamp: Date; | ||
level: LogLevel; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the first big pain point of the PR. The config service relies on the logger
service, and tests depends on the logging mocks. At first I wanted to duplicate the interface of Logger
and LoggerFactory
, but of course they relies on lot of other types from the core/server/logging module, and that doesn't solves the mock class issue.
I don't really see any other option than creating a @kbn/logging
package here... 'Good' new is that it is the only service config
depends on. But I still don't really like that, because I'm afraid we will be ending with a package per core service...
wdyt?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't really see any other option than creating a @kbn/logging package here.
Maybe this isn't such a bad idea. Without such a package we have to duplicate the logging interface in other packages. For example, ToolingLog
in
https://github.com/elastic/kibana/tree/ab226f02ae12f0f8a2ec1ff5ba604569cd8d4b68/packages/kbn-dev-utils/src/tooling_log
It might be not that simple though. The logging service consumes the config service, so we would have to decouple them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The logging service consumes the config service, so we would have to decouple them.
I forget that CoreContext
had a reference to the config service. However the LoggingService
doesn't seems like it is using it. Or did I overlook a usage somewhere?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok, I don't see it's used anywhere
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it make sense or be more convenient to mix these two things into the same package? While they're mostly separate concerns, I suspect most usages of config will also want to use logging. Rather than trying to pull this all apart now, maybe just keeping them together in a @kbn/base
package would be a good practical step for now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure it would really be easier to have these two things in the same package. The only logger
->config
coupling is via the coreContext
type, and this can probably be adapted as the logger service does not actually uses it.
I think having two package would avoid to introduce more coupling into these things if/when we decide to split them in distinct packages.
Created #77149 as a POC of creating the logging package. If that's acceptable, I'll reintegrate the changes in this PR.
packages/kbn-config/src/utils/get.ts
Outdated
export function get<CFG extends { [k: string]: any }>(obj: CFG, path: string[] | string): any { | ||
if (typeof path === 'string') { | ||
if (path.includes('.')) { | ||
throw new Error('Using dots in `get` with a string is not allowed, use array instead'); | ||
} | ||
|
||
return obj[path]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Another issue moving this code to a package: It was using the get
, unset
and getFlattenedObject
utils defined in the src/core/utils
module.
I duplicated them for now. I feel like the proper solution would be to move all the src/core/utils
folder to a package, either an already existing one (not sure which...), or a new one.
wdyt?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've already faced the same problem. #76397 (comment)
I'm not a fan of utils
, but it seems to be the pragmatic step. It would be great to discuss it with the @elastic/kibana-operations
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Created #76925
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Left a comment in #76925, but I'd prefer a @kbn/std
package for lodash-like utilities.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I also think copying for now is totally fine. We don't need to necessarily create that package until we have a need in severl places (which maybe we already do)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yea, that's not a blocker. having the issue to track is probably good enough for now.
ConfigDeprecationFactory, | ||
coreDeprecationProvider, | ||
} from './deprecation'; | ||
|
||
export { EnvironmentMode, PackageInfo } from './types'; | ||
EnvironmentMode, | ||
PackageInfo, | ||
LegacyObjectToConfigAdapter, | ||
} from '@kbn/config'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm re-exporting from the new package all the things that were previously in this module. That felt like the most pragmatic approach. Not sure how this behave with the api-extractor though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure how this behave with the api-extractor though.
AFAIK api-extractor
keeps it as it's declared microsoft/rushstack#1791
packages/kbn-config/src/index.ts
Outdated
// mocks | ||
export { configMock } from './config.mock'; | ||
export { configServiceMock } from './config_service.mock'; | ||
export { rawConfigServiceMock } from './raw/raw_config_service.mock'; | ||
export { getEnvOptions } from './__mocks__/env'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As these mocks are used in core
, I had to expose them on the package's entrypoint. This feels wrong, but I think creating an additional @kbn/config-mocks
package is overkill, wdyt?
I couldn't find a way to have something like import { rawConfigServiceMock } from '@kbn/config/mocks'
, as I was forced to do import { rawConfigServiceMock } from '@kbn/config/target/out/mocks'
. Maybe someone has more knowledge than me on npm packages?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Our nodejs version doesn't support exports
https://nodejs.org/docs/latest-v12.x/api/esm.html#esm_main_entry_point_export
We could emit *.js
files next to *.ts
and ignore them in .gitignore
.
@elastic/kibana-operations any other ideas?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since we build in place and can't produce the JS at the root of the module, I don't see any other alternative. Sounds like the best thing right now would be to use target in the import until we upgrade to v12.
packages/kbn-config/src/env.ts
Outdated
const pkg = require('../../../../package.json'); | ||
const pkg = require('../../../package.json'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Now that this is in a package, these hardcoded requires won't work anymore, as the compiled file in node_modules
it not at the same place, or depth, than in the source. I think we don't have any other option than using the REPO_ROOT
constant from @kbn/dev-utils
(same lower in file)
Note that as REPO_ROOT
is an absolute path, we won't be able to require
it and we'll have to fallback to read and parse the file 'manually'.
The mocking (see packages/kbn-config/src/env.test.mocks.ts
) will have to be adapted too.
EDIT: done. Fun fact, tests that are mocking the fs
package are now exploding because REPO_ROOT
is computed at module load.
kibana/packages/kbn-dev-utils/src/repo_root.ts
Lines 47 to 59 in 7b4278d
while (true) { | |
if (isKibanaDir(cursor)) { | |
break; | |
} | |
const parent = Path.dirname(cursor); | |
if (parent === rootDir) { | |
throw new Error(`unable to find kibana directory from ${startDir}`); | |
} | |
cursor = parent; | |
} | |
export const REPO_ROOT = cursor; |
It's quite bad because it's not only impacting core
tests, some xpack tests are also failing because of that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Commented on this here: #76874 (comment)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
#76518 is almost ready for review including resolving the tests mocking fs by being explicit about the actual files they wish to mock -
import { ConfigDeprecation } from '@kbn/config'; | ||
import { ConfigDeprecationFactory } from '@kbn/config'; | ||
import { ConfigDeprecationLogger } from '@kbn/config'; | ||
import { ConfigDeprecationProvider } from '@kbn/config'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Another issue moving these to a package: The doc files are no longer generated, as they are imported/exported from the package. See 545c867. Not sure if we have a solution for that
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we do. @kbn/config
becomes an external package for src/core
, so api-extractor
terminates traversing at this point. Investigation required to understand whether we can link types between packages. It's not supported microsoft/rushstack#1596
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So by extracting config
, and logging
outside of core, we basically are loosing the documentation for their types.
Would generating doc from these package solve this? I guess core
and @kbn/xxx
generated doc would not be able to link to each other...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess core and @kbn/xxx generated doc would not be able to link to each other...
Right, in the issue I attached discussed that this use-case is not supported out-of-the-box. We might have to contribute to api-extractor
to support this. Even a link to @kbn/xxx
package would be good start.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we create an issue to contribute to api-extractor
? @joshdover
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Created #77529 as a discussion issue
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The only major downside from this PR is the impact on the api-extractor documentation that does not work with re-exports or references to types from another package. I still feel like it shouldn't be considered blocker, and I think the solution would be to fix the extractor instead at some point (see #76874 (comment)), as the 'move to package' approach is still, in my opinion, the only valid one if we want to start exposing services such as config and logging to code outside of the core platform.
Provider for the [ConfigDeprecation](./kibana-plugin-core-server.configdeprecation.md) to apply to the plugin configuration. | ||
Provider for the to apply to the plugin configuration. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Links to types moved in the logging
and config
packages do no longer work. Not sure there is anything we can do unfortunately.
import { Logger } from '@kbn/logging'; | ||
import { LogMeta } from '@kbn/logging'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@elastic/kibana-app-arch The additional imports in src/plugins/data/public/public.api.md
and src/plugins/data/server/server.api.md
should be the only changes impacting you
// Warning: (ae-unresolved-link) The @link reference could not be resolved: Reexported declarations are not supported | ||
readonly configPath: ConfigPath; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Another downside of moving the types to a package regarding documentation
export const loggerMock = { | ||
create: createLoggerMock, | ||
}; | ||
export { loggerMock, MockedLogger } from '@kbn/logging/target/mocks'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I kept this file and just re-exported the mock that got moved in the logging package to avoid adding 100+ import changes to the diff. Overall, I think it's going to be a good practice to have package-reexporting modules if we move things out of core.
src/core/server/bootstrap.ts
Outdated
// `bootstrap` is exported from the `src/core/server/index` module, | ||
// meaning that any test importing, implicitly or explicitly, anything concrete | ||
// from `core/server` will load `dev-utils`. As some tests are mocking the `fs` package, | ||
// and as `REPO_ROOT` is initialized on the fly when importing `dev-utils` and requires | ||
// the `fs` package, it causes failures. This is why we use a dynamic `require` here. | ||
// eslint-disable-next-line @typescript-eslint/no-var-requires | ||
const { REPO_ROOT } = require('@kbn/dev-utils'); | ||
|
||
const env = Env.createDefault(REPO_ROOT, { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Self explanatory comment. May be resolved by #76518. See main issue description for more info.
packages/kbn-config/README.md
Outdated
`@kbn/config-schema` is a TypeScript library inspired by Joi and designed to allow run-time validation of the | ||
Kibana configuration entries providing developers with a fully typed model of the validated data. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This reference to @kbn/config-schema
is rather confusing. Isn't it? Let's remove it
|
||
Base types for the kibana platform logging system. | ||
|
||
Note that this package currently only contains logging types. The only concrete implementation |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What prevents us from moving the implementation to the package? Should we create an issue to move the implementation to the package?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The base classes such as BaseLogger
and LoggerAdapter
could be moved without any issue.
The main issue is about the appenders, that are currently importing code from legacy, which are themselves importing a whole lot of dependencies that we can't extract to the new package.
kibana/src/core/server/logging/appenders/appenders.ts
Lines 24 to 27 in 92243ba
import { | |
LegacyAppender, | |
LegacyAppenderConfig, | |
} from '../../legacy/logging/appenders/legacy_appender'; |
We would need to adapt the Appenders
class to allow registration of appenders + their associated config schema. That way, we could have the base appenders in the package, and the legacy appender only defined and registered inside core. But this is not trivial, as the schema registration would have to be performed before validating the actual configuration file. This is why I'm keeping this for later.
@@ -17,15 +17,16 @@ | |||
* under the License. | |||
*/ | |||
|
|||
// must be before mocks imports to avoid conflicting with `REPO_ROOT` accessor. | |||
import { REPO_ROOT } from '@kbn/dev-utils'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The package is stateful and the wrong import order blows out the tests? That's not good 😞
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yea. The package is stateful + it depends on fs.readFileSync
for the REPO_ROOT initialization, so it's really awkward ina few testing scenarios. #76518 is supposed to adapt the tests mocking the whole fs
package to only mock specific files to address this...
import { ConfigDeprecation } from '@kbn/config'; | ||
import { ConfigDeprecationFactory } from '@kbn/config'; | ||
import { ConfigDeprecationLogger } from '@kbn/config'; | ||
import { ConfigDeprecationProvider } from '@kbn/config'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we create an issue to contribute to api-extractor
? @joshdover
@@ -0,0 +1,3 @@ | |||
# `@kbn/config` — Kibana configuration file loader | |||
|
|||
This package contains the configuration service used to load and read the kibana configuration file |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you include some basic usage information here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yea, in the follow-up, as there is currently no way to properly use the configuration service that has been extracted. (This is only step 1 of #76003, PR would have been too big otherwise)
💚 Build SucceededBuild metrics@kbn/optimizer bundle module count
async chunks size
page load bundle size
distributable file count
History
To update your PR or re-run it, just comment with: |
* move deprecations and raw loader to package * move config service to package * start to adapt the usages * adapt yet more usages * update generated doc * move logging types to `@kbn/logging` * update generated doc * add yarn.lock symlink * merge @kbn-logging PR * adapt Env.createDefault * update generated doc * remove mock exports from the main entrypoint to avoid importing it in production code * use dynamic require to import `REPO_ROOT` from bootstrap file * move logger mock to kbn-logging package * address review comments * import PublicMethodOf from kbn/utility-types * fix import conflict * update generated doc * use the @kbn/std package * update generated doc * adapt plugin service mock
…s-for-710 * 'master' of github.com:elastic/kibana: (95 commits) log request body in new ES client (elastic#77150) use `navigateToUrl` to navigate to recent nav links (elastic#77446) Move core config service to `kbn/config` package (elastic#76874) [UBI] Copy license to /licenses folder (elastic#77563) Skip flaky Events Viewer Cypress test [Lens] Remove dynamic names in telemetry fields (elastic#76988) [Maps] Add DynamicStyleProperty#getMbPropertyName and DynamicStyleProperty#getMbPropertyValue (elastic#77366) [Enterprise Search] Add flag to restrict width of layout (elastic#77539) [Security Solutions][Cases - Timeline] Fix bug when adding a timeline to a case (elastic#76967) [Security Solution][Detections] Integration test for Editing a Rule (elastic#77090) [Ingest pipelines] Polish pipeline debugging workflow (elastic#76058) [@kbn/utils] Adds missing dependency (elastic#77536) Add the Enterprise Search logo to the Overview search result (elastic#77514) [Logs UI] [Metrics UI] Remove saved object field mappings (elastic#75482) [Security Solution][Exceptions] Exception modal bulk close option only closes alerts generated by same rule (elastic#77402) Adds @kbn/utils package (elastic#76518) Map layout changes (elastic#77132) [Security Solution] [Detections] EQL Rule Creation (elastic#76831) Adding test user to maps tests under documents source folder (elastic#77245) Suppress error logs when clients connect over HTTP instead of HTTPS (elastic#77397) ... # Conflicts: # x-pack/plugins/index_lifecycle_management/public/application/sections/edit_policy/components/index.ts # x-pack/plugins/index_lifecycle_management/public/application/sections/edit_policy/phases/warm_phase.tsx
* move deprecations and raw loader to package * move config service to package * start to adapt the usages * adapt yet more usages * update generated doc * move logging types to `@kbn/logging` * update generated doc * add yarn.lock symlink * merge @kbn-logging PR * adapt Env.createDefault * update generated doc * remove mock exports from the main entrypoint to avoid importing it in production code * use dynamic require to import `REPO_ROOT` from bootstrap file * move logger mock to kbn-logging package * address review comments * import PublicMethodOf from kbn/utility-types * fix import conflict * update generated doc * use the @kbn/std package * update generated doc * adapt plugin service mock
* master: (55 commits) [Grok] Fix missing error message in error toasts (elastic#77499) [Alerting] Exempt Alerts pre 7.10 from RBAC on their Action execution until updated (elastic#75563) [ML] fix type in apply_influencer_filters_action (elastic#77495) [Lens] create reusable component for filters and range aggregation (elastic#77453) fix eslint violations Collapse alert chart previews by default (elastic#77479) [ML] Fixing field caps wrapper endpoint (elastic#77546) showing service maps when filte by environment not defined (elastic#77483) [Lens] Settings panel redesign and separate settings per y axis (elastic#76373) log request body in new ES client (elastic#77150) use `navigateToUrl` to navigate to recent nav links (elastic#77446) Move core config service to `kbn/config` package (elastic#76874) [UBI] Copy license to /licenses folder (elastic#77563) Skip flaky Events Viewer Cypress test [Lens] Remove dynamic names in telemetry fields (elastic#76988) [Maps] Add DynamicStyleProperty#getMbPropertyName and DynamicStyleProperty#getMbPropertyValue (elastic#77366) [Enterprise Search] Add flag to restrict width of layout (elastic#77539) [Security Solutions][Cases - Timeline] Fix bug when adding a timeline to a case (elastic#76967) [Security Solution][Detections] Integration test for Editing a Rule (elastic#77090) [Ingest pipelines] Polish pipeline debugging workflow (elastic#76058) ...
* master: (54 commits) [Grok] Fix missing error message in error toasts (elastic#77499) [Alerting] Exempt Alerts pre 7.10 from RBAC on their Action execution until updated (elastic#75563) [ML] fix type in apply_influencer_filters_action (elastic#77495) [Lens] create reusable component for filters and range aggregation (elastic#77453) fix eslint violations Collapse alert chart previews by default (elastic#77479) [ML] Fixing field caps wrapper endpoint (elastic#77546) showing service maps when filte by environment not defined (elastic#77483) [Lens] Settings panel redesign and separate settings per y axis (elastic#76373) log request body in new ES client (elastic#77150) use `navigateToUrl` to navigate to recent nav links (elastic#77446) Move core config service to `kbn/config` package (elastic#76874) [UBI] Copy license to /licenses folder (elastic#77563) Skip flaky Events Viewer Cypress test [Lens] Remove dynamic names in telemetry fields (elastic#76988) [Maps] Add DynamicStyleProperty#getMbPropertyName and DynamicStyleProperty#getMbPropertyValue (elastic#77366) [Enterprise Search] Add flag to restrict width of layout (elastic#77539) [Security Solutions][Cases - Timeline] Fix bug when adding a timeline to a case (elastic#76967) [Security Solution][Detections] Integration test for Editing a Rule (elastic#77090) [Ingest pipelines] Polish pipeline debugging workflow (elastic#76058) ...
* master: (76 commits) Fixing service maps API test (elastic#77586) [Grok] Fix missing error message in error toasts (elastic#77499) [Alerting] Exempt Alerts pre 7.10 from RBAC on their Action execution until updated (elastic#75563) [ML] fix type in apply_influencer_filters_action (elastic#77495) [Lens] create reusable component for filters and range aggregation (elastic#77453) fix eslint violations Collapse alert chart previews by default (elastic#77479) [ML] Fixing field caps wrapper endpoint (elastic#77546) showing service maps when filte by environment not defined (elastic#77483) [Lens] Settings panel redesign and separate settings per y axis (elastic#76373) log request body in new ES client (elastic#77150) use `navigateToUrl` to navigate to recent nav links (elastic#77446) Move core config service to `kbn/config` package (elastic#76874) [UBI] Copy license to /licenses folder (elastic#77563) Skip flaky Events Viewer Cypress test [Lens] Remove dynamic names in telemetry fields (elastic#76988) [Maps] Add DynamicStyleProperty#getMbPropertyName and DynamicStyleProperty#getMbPropertyValue (elastic#77366) [Enterprise Search] Add flag to restrict width of layout (elastic#77539) [Security Solutions][Cases - Timeline] Fix bug when adding a timeline to a case (elastic#76967) [Security Solution][Detections] Integration test for Editing a Rule (elastic#77090) ...
Summary
part of #76003
What the PR does:
src/core/logging
types and theLogger
mock to a new@kbn/logging
package.src/core/config
code (except core deprecations for now) into a new@kbn/config
package.Env
type, and mostlyEnv.createDefault
, to now explicitly pass therepoRoot
parameter. This is mostly driven by test needs, and caused by the fact that we can no longerrequire
thepackage.json
file and now need to use theREPO_ROOT
constant instead.Regarding
Env
changes: I know that #76518 is suppose to address the issue I had to resolve here, but this is mostly impacting test files (the only production code change is inbootstrap
), so I think this is acceptable if we don't want to loose to much time. We still can 'revert' theEnv.createDefault
signature change once #76518 lands if it fully solves our issues.What part of #76003 is not addressed in this PR
@kbn-config
@kbn-config
to easily instanciate a configuredConfigService
to be used from outside of the platform environment.Moving the schemas may be non trivial depending on the coupling with the equivalent types. As the PR is already big and got some significant structural changes, so I would like to handle this in a follow-up, if this is alright with everyone.
What is outside of the scope of the PR:
@kbn/logging
This is outside of the scope of #76003, and even if we know we want this, it's currently blocked by the legacy appender, so doing it after the legacy logging has been removed would really facilitate that.
Checklist