Add conditional switching between EUI releases#219818
Merged
tkajtoch merged 11 commits intoelastic:mainfrom May 28, 2025
Merged
Add conditional switching between EUI releases#219818tkajtoch merged 11 commits intoelastic:mainfrom
tkajtoch merged 11 commits intoelastic:mainfrom
Conversation
tkajtoch
added
release_note:skip
Collaborator
🎉 Snyk checks have passed. No issues have been found so far.✅ security/snyk check is complete. No issues have been found. (View Details) ✅ license/snyk check is complete. No issues have been found. (View Details) |
tkajtoch
force-pushed
the
build/eui-amsterdam-setup
branch
2 times, most recently
from
0d3c79b to
717cccf
Compare
mistic
reviewed
May 21, 2025
mistic
reviewed
May 21, 2025
| '@elastic/eui$': useEuiAmsterdamRelease | ||
| ? '@elastic/eui-amsterdam/optimize/es' | ||
| : '@elastic/eui/optimize/es', | ||
| '@elastic/eui/optimize/es/components/provider/nested$': useEuiAmsterdamRelease |
Contributor
There was a problem hiding this comment.
I can be wrong but last time I checked I thought we are not using the @elastic/eui/optimize/es/components|services here but I don't think it is hurting having those here as well
Member
Author
There was a problem hiding this comment.
They're imported here https://github.com/elastic/kibana/pull/219818/files#diff-297b98e7425a61eaaeffb43396acf6d43fd67af9971601463803aa4d0d874a96R67-R68 and if I skipped them they got imported from the original package. I decided to keep them configured the same as in shared-deps-src which seems to do the trick and keeps everything aligned
tkajtoch
added
backport:prev-minor
v9.0.3
v8.19.0
backport:version
…ck configs to use the @elastic/eui-amsterdam package conditionally
…t --include-path /api/status --include-path /api/alerting/rule/ --include-path /api/alerting/rules --include-path /api/actions --include-path /api/security/role --include-path /api/spaces --include-path /api/streams --include-path /api/fleet --include-path /api/dashboards --include-path /api/saved_objects/_import --include-path /api/saved_objects/_export --include-path /api/alerting/maintenance_window --update'
Contributor
💛 Build succeeded, but was flaky
Failed CI StepsMetrics [docs]
History
cc @tkajtoch |
Contributor
|
Starting backport for target branches: 8.19, 9.0 https://github.com/elastic/kibana/actions/runs/15301720021 |
Contributor
💔 All backports failed
Manual backportTo create the backport manually run: Questions ?Please refer to the Backport tool documentation |
1 task
akowalska622
pushed a commit
to akowalska622/kibana
that referenced
this pull request
May 29, 2025
## Summary This PR simplifies the weekly EUI upgrade and backport process by conditionally aliasing `@elastic/eui` in shared deps webpack configurations. # Backstory The EUI team (@elastic/eui-team) is responsible for keeping EUI up to date in Kibana. Historically, this has been a relatively straightforward (yet time-consuming) process, however, due to `8.x` backport complexities caused by it using a different theme, it has become way more demanding on everybody involved. EUI is released on weekly basis. Each week, we release official EUI versions tagged `latest` in npmjs and get a PR open that updates the package in kibana `main`. Our upgrade PRs tend to require anywhere between 2 and 25 codeowner reviews due to the number of snapshots we need to update while working on the EUI upgrade PRs. These snapshot changes are 99% of the time harmless, yet it still takes 2+ full workdays to ping teams and get all reviews necessary to get the PR merged. Generally speaking, we aim to have the upgrade PR open on Monday and merged by Friday. ## The issue with `8.x` backports Kibana 8.x uses the Amsterdam theme instead of Borealis, which is used in Kibana 9.0 and up. To keep 8.x up to date, for each official EUI release we prepare another special Kibana 8.x only release of EUI (e.g., `101.2.0-amsterdam.0`). These special releases have the theme hardcoded to Amsterdam at compile-time to avoid any initial theme errors Kibana could otherwise experience. This is done primarily because some areas in Kibana read EUI theme values outside of React components, and we have no stable way to determine what the active theme is since there's no context information. This is where we need to fall back to Amsterdam in 8.x and Borealis in 9.x. **Since there are two different EUI versions - one for Kibana `main` and 9.0, and another for 8.x branches, we cannot use the automated backports feature**. Instead, we open two separate PRs and configure backport labels accordingly. Having two PRs is far from ideal since codeowners need to review our changes twice, and we're more likely to make mistakes. # Our proposal Following the recently introduced React version switching logic, we want to conditionally switch between two `@elastic/eui` releases depending on the kibana branch/version while keeping automated backports possible. To achieve that, I added a dependency alias `@elastic/eui-amsterdam` that points to the Amsterdam EUI release and configured `resolve.alias` in shared deps to resolve the correct dependency based on the optional `EUI_AMSTERDAM` environment variable. When this change is merged to `main` and backported to `9.0` and `8.19`, I'll open a follow-up PR to the `8.19` branch updating the default value of `EUI_AMSTERDAM` to `"true"`. This should result in no conflicts and be easy to follow. Since 8.19 [uses the Amsterdam release of `@elastic/eui`](https://github.com/elastic/kibana/blob/8.19/package.json#L126) (e.g., `101.2.0-amsterdam.0`), there's no risk backporting this PR as-is without `EUI_AMSTERDAM` configured beforehand. ## What does it change? With this setup, we'll be able to update versions of `@elastic/eui` and `@elastic/eui-amsterdam` at the same time in a single PR and make use of automated kibana backports. There will be only one set of changes to review by codeowners, and if there are any failing tests when backporting to `8.19` due to, for example, changed color values, we can follow the regular kibana procedures and fix them right in the created backport PR. It'll simplify our workflow quite drastically while keeping the same level of quality. --------- Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
tkajtoch
added a commit
to tkajtoch/kibana
that referenced
this pull request
May 29, 2025
## Summary This PR simplifies the weekly EUI upgrade and backport process by conditionally aliasing `@elastic/eui` in shared deps webpack configurations. # Backstory The EUI team (@elastic/eui-team) is responsible for keeping EUI up to date in Kibana. Historically, this has been a relatively straightforward (yet time-consuming) process, however, due to `8.x` backport complexities caused by it using a different theme, it has become way more demanding on everybody involved. EUI is released on weekly basis. Each week, we release official EUI versions tagged `latest` in npmjs and get a PR open that updates the package in kibana `main`. Our upgrade PRs tend to require anywhere between 2 and 25 codeowner reviews due to the number of snapshots we need to update while working on the EUI upgrade PRs. These snapshot changes are 99% of the time harmless, yet it still takes 2+ full workdays to ping teams and get all reviews necessary to get the PR merged. Generally speaking, we aim to have the upgrade PR open on Monday and merged by Friday. ## The issue with `8.x` backports Kibana 8.x uses the Amsterdam theme instead of Borealis, which is used in Kibana 9.0 and up. To keep 8.x up to date, for each official EUI release we prepare another special Kibana 8.x only release of EUI (e.g., `101.2.0-amsterdam.0`). These special releases have the theme hardcoded to Amsterdam at compile-time to avoid any initial theme errors Kibana could otherwise experience. This is done primarily because some areas in Kibana read EUI theme values outside of React components, and we have no stable way to determine what the active theme is since there's no context information. This is where we need to fall back to Amsterdam in 8.x and Borealis in 9.x. **Since there are two different EUI versions - one for Kibana `main` and 9.0, and another for 8.x branches, we cannot use the automated backports feature**. Instead, we open two separate PRs and configure backport labels accordingly. Having two PRs is far from ideal since codeowners need to review our changes twice, and we're more likely to make mistakes. # Our proposal Following the recently introduced React version switching logic, we want to conditionally switch between two `@elastic/eui` releases depending on the kibana branch/version while keeping automated backports possible. To achieve that, I added a dependency alias `@elastic/eui-amsterdam` that points to the Amsterdam EUI release and configured `resolve.alias` in shared deps to resolve the correct dependency based on the optional `EUI_AMSTERDAM` environment variable. When this change is merged to `main` and backported to `9.0` and `8.19`, I'll open a follow-up PR to the `8.19` branch updating the default value of `EUI_AMSTERDAM` to `"true"`. This should result in no conflicts and be easy to follow. Since 8.19 [uses the Amsterdam release of `@elastic/eui`](https://github.com/elastic/kibana/blob/8.19/package.json#L126) (e.g., `101.2.0-amsterdam.0`), there's no risk backporting this PR as-is without `EUI_AMSTERDAM` configured beforehand. ## What does it change? With this setup, we'll be able to update versions of `@elastic/eui` and `@elastic/eui-amsterdam` at the same time in a single PR and make use of automated kibana backports. There will be only one set of changes to review by codeowners, and if there are any failing tests when backporting to `8.19` due to, for example, changed color values, we can follow the regular kibana procedures and fix them right in the created backport PR. It'll simplify our workflow quite drastically while keeping the same level of quality. --------- Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com> (cherry picked from commit ac3fc27) # Conflicts: # src/platform/packages/private/kbn-ui-shared-deps-npm/BUILD.bazel # src/platform/packages/private/kbn-ui-shared-deps-src/BUILD.bazel
Member
Author
💚 All backports created successfully
Note: Successful backport PRs will be merged automatically after passing CI. Questions ?Please refer to the Backport tool documentation |
tkajtoch
added a commit
to tkajtoch/kibana
that referenced
this pull request
May 29, 2025
## Summary This PR simplifies the weekly EUI upgrade and backport process by conditionally aliasing `@elastic/eui` in shared deps webpack configurations. # Backstory The EUI team (@elastic/eui-team) is responsible for keeping EUI up to date in Kibana. Historically, this has been a relatively straightforward (yet time-consuming) process, however, due to `8.x` backport complexities caused by it using a different theme, it has become way more demanding on everybody involved. EUI is released on weekly basis. Each week, we release official EUI versions tagged `latest` in npmjs and get a PR open that updates the package in kibana `main`. Our upgrade PRs tend to require anywhere between 2 and 25 codeowner reviews due to the number of snapshots we need to update while working on the EUI upgrade PRs. These snapshot changes are 99% of the time harmless, yet it still takes 2+ full workdays to ping teams and get all reviews necessary to get the PR merged. Generally speaking, we aim to have the upgrade PR open on Monday and merged by Friday. ## The issue with `8.x` backports Kibana 8.x uses the Amsterdam theme instead of Borealis, which is used in Kibana 9.0 and up. To keep 8.x up to date, for each official EUI release we prepare another special Kibana 8.x only release of EUI (e.g., `101.2.0-amsterdam.0`). These special releases have the theme hardcoded to Amsterdam at compile-time to avoid any initial theme errors Kibana could otherwise experience. This is done primarily because some areas in Kibana read EUI theme values outside of React components, and we have no stable way to determine what the active theme is since there's no context information. This is where we need to fall back to Amsterdam in 8.x and Borealis in 9.x. **Since there are two different EUI versions - one for Kibana `main` and 9.0, and another for 8.x branches, we cannot use the automated backports feature**. Instead, we open two separate PRs and configure backport labels accordingly. Having two PRs is far from ideal since codeowners need to review our changes twice, and we're more likely to make mistakes. # Our proposal Following the recently introduced React version switching logic, we want to conditionally switch between two `@elastic/eui` releases depending on the kibana branch/version while keeping automated backports possible. To achieve that, I added a dependency alias `@elastic/eui-amsterdam` that points to the Amsterdam EUI release and configured `resolve.alias` in shared deps to resolve the correct dependency based on the optional `EUI_AMSTERDAM` environment variable. When this change is merged to `main` and backported to `9.0` and `8.19`, I'll open a follow-up PR to the `8.19` branch updating the default value of `EUI_AMSTERDAM` to `"true"`. This should result in no conflicts and be easy to follow. Since 8.19 [uses the Amsterdam release of `@elastic/eui`](https://github.com/elastic/kibana/blob/8.19/package.json#L126) (e.g., `101.2.0-amsterdam.0`), there's no risk backporting this PR as-is without `EUI_AMSTERDAM` configured beforehand. ## What does it change? With this setup, we'll be able to update versions of `@elastic/eui` and `@elastic/eui-amsterdam` at the same time in a single PR and make use of automated kibana backports. There will be only one set of changes to review by codeowners, and if there are any failing tests when backporting to `8.19` due to, for example, changed color values, we can follow the regular kibana procedures and fix them right in the created backport PR. It'll simplify our workflow quite drastically while keeping the same level of quality. --------- Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com> (cherry picked from commit ac3fc27) # Conflicts: # package.json # packages/kbn-dependency-ownership/src/rule.ts # src/dev/license_checker/config.ts # src/platform/packages/private/kbn-ui-shared-deps-npm/BUILD.bazel # src/platform/packages/private/kbn-ui-shared-deps-src/BUILD.bazel # yarn.lock
This was referenced May 29, 2025
tkajtoch
added a commit
that referenced
this pull request
May 29, 2025
) # Backport This will backport the following commits from `main` to `8.19`: - [Add conditional switching between EUI releases (#219818)](#219818) <!--- Backport version: 10.0.0 --> ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sorenlouv/backport) <!--BACKPORT [{"author":{"name":"Tomasz Kajtoch","email":"tomasz.kajtoch@elastic.co"},"sourceCommit":{"committedDate":"2025-05-28T13:41:19Z","message":"Add conditional switching between EUI releases (#219818)\n\n## Summary\n\nThis PR simplifies the weekly EUI upgrade and backport process by\nconditionally aliasing `@elastic/eui` in shared deps webpack\nconfigurations.\n\n# Backstory\n\nThe EUI team (@elastic/eui-team) is responsible for keeping EUI up to\ndate in Kibana. Historically, this has been a relatively straightforward\n(yet time-consuming) process, however, due to `8.x` backport\ncomplexities caused by it using a different theme, it has become way\nmore demanding on everybody involved.\n\nEUI is released on weekly basis. Each week, we release official EUI\nversions tagged `latest` in npmjs and get a PR open that updates the\npackage in kibana `main`.\n\nOur upgrade PRs tend to require anywhere between 2 and 25 codeowner\nreviews due to the number of snapshots we need to update while working\non the EUI upgrade PRs. These snapshot changes are 99% of the time\nharmless, yet it still takes 2+ full workdays to ping teams and get all\nreviews necessary to get the PR merged. Generally speaking, we aim to\nhave the upgrade PR open on Monday and merged by Friday.\n\n## The issue with `8.x` backports\n\nKibana 8.x uses the Amsterdam theme instead of Borealis, which is used\nin Kibana 9.0 and up. To keep 8.x up to date, for each official EUI\nrelease we prepare another special Kibana 8.x only release of EUI (e.g.,\n`101.2.0-amsterdam.0`). These special releases have the theme hardcoded\nto Amsterdam at compile-time to avoid any initial theme errors Kibana\ncould otherwise experience. This is done primarily because some areas in\nKibana read EUI theme values outside of React components, and we have no\nstable way to determine what the active theme is since there's no\ncontext information. This is where we need to fall back to Amsterdam in\n8.x and Borealis in 9.x.\n\n**Since there are two different EUI versions - one for Kibana `main` and\n9.0, and another for 8.x branches, we cannot use the automated backports\nfeature**. Instead, we open two separate PRs and configure backport\nlabels accordingly. Having two PRs is far from ideal since codeowners\nneed to review our changes twice, and we're more likely to make\nmistakes.\n\n# Our proposal\n\nFollowing the recently introduced React version switching logic, we want\nto conditionally switch between two `@elastic/eui` releases depending on\nthe kibana branch/version while keeping automated backports possible.\n\nTo achieve that, I added a dependency alias `@elastic/eui-amsterdam`\nthat points to the Amsterdam EUI release and configured `resolve.alias`\nin shared deps to resolve the correct dependency based on the optional\n`EUI_AMSTERDAM` environment variable. When this change is merged to\n`main` and backported to `9.0` and `8.19`, I'll open a follow-up PR to\nthe `8.19` branch updating the default value of `EUI_AMSTERDAM` to\n`\"true\"`. This should result in no conflicts and be easy to follow.\n\nSince 8.19 [uses the Amsterdam release of\n`@elastic/eui`](https://github.com/elastic/kibana/blob/8.19/package.json#L126)\n(e.g., `101.2.0-amsterdam.0`), there's no risk backporting this PR as-is\nwithout `EUI_AMSTERDAM` configured beforehand.\n\n## What does it change?\n\nWith this setup, we'll be able to update versions of `@elastic/eui` and\n`@elastic/eui-amsterdam` at the same time in a single PR and make use of\nautomated kibana backports. There will be only one set of changes to\nreview by codeowners, and if there are any failing tests when\nbackporting to `8.19` due to, for example, changed color values, we can\nfollow the regular kibana procedures and fix them right in the created\nbackport PR. It'll simplify our workflow quite drastically while keeping\nthe same level of quality.\n\n---------\n\nCo-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>","sha":"ac3fc27a5397456630f974f84bee64f597500b55","branchLabelMapping":{"^v9.1.0$":"main","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["release_note:skip","backport:version","v9.1.0","v8.19.0","v9.0.3"],"title":"Add conditional switching between EUI releases","number":219818,"url":"https://github.com/elastic/kibana/pull/219818","mergeCommit":{"message":"Add conditional switching between EUI releases (#219818)\n\n## Summary\n\nThis PR simplifies the weekly EUI upgrade and backport process by\nconditionally aliasing `@elastic/eui` in shared deps webpack\nconfigurations.\n\n# Backstory\n\nThe EUI team (@elastic/eui-team) is responsible for keeping EUI up to\ndate in Kibana. Historically, this has been a relatively straightforward\n(yet time-consuming) process, however, due to `8.x` backport\ncomplexities caused by it using a different theme, it has become way\nmore demanding on everybody involved.\n\nEUI is released on weekly basis. Each week, we release official EUI\nversions tagged `latest` in npmjs and get a PR open that updates the\npackage in kibana `main`.\n\nOur upgrade PRs tend to require anywhere between 2 and 25 codeowner\nreviews due to the number of snapshots we need to update while working\non the EUI upgrade PRs. These snapshot changes are 99% of the time\nharmless, yet it still takes 2+ full workdays to ping teams and get all\nreviews necessary to get the PR merged. Generally speaking, we aim to\nhave the upgrade PR open on Monday and merged by Friday.\n\n## The issue with `8.x` backports\n\nKibana 8.x uses the Amsterdam theme instead of Borealis, which is used\nin Kibana 9.0 and up. To keep 8.x up to date, for each official EUI\nrelease we prepare another special Kibana 8.x only release of EUI (e.g.,\n`101.2.0-amsterdam.0`). These special releases have the theme hardcoded\nto Amsterdam at compile-time to avoid any initial theme errors Kibana\ncould otherwise experience. This is done primarily because some areas in\nKibana read EUI theme values outside of React components, and we have no\nstable way to determine what the active theme is since there's no\ncontext information. This is where we need to fall back to Amsterdam in\n8.x and Borealis in 9.x.\n\n**Since there are two different EUI versions - one for Kibana `main` and\n9.0, and another for 8.x branches, we cannot use the automated backports\nfeature**. Instead, we open two separate PRs and configure backport\nlabels accordingly. Having two PRs is far from ideal since codeowners\nneed to review our changes twice, and we're more likely to make\nmistakes.\n\n# Our proposal\n\nFollowing the recently introduced React version switching logic, we want\nto conditionally switch between two `@elastic/eui` releases depending on\nthe kibana branch/version while keeping automated backports possible.\n\nTo achieve that, I added a dependency alias `@elastic/eui-amsterdam`\nthat points to the Amsterdam EUI release and configured `resolve.alias`\nin shared deps to resolve the correct dependency based on the optional\n`EUI_AMSTERDAM` environment variable. When this change is merged to\n`main` and backported to `9.0` and `8.19`, I'll open a follow-up PR to\nthe `8.19` branch updating the default value of `EUI_AMSTERDAM` to\n`\"true\"`. This should result in no conflicts and be easy to follow.\n\nSince 8.19 [uses the Amsterdam release of\n`@elastic/eui`](https://github.com/elastic/kibana/blob/8.19/package.json#L126)\n(e.g., `101.2.0-amsterdam.0`), there's no risk backporting this PR as-is\nwithout `EUI_AMSTERDAM` configured beforehand.\n\n## What does it change?\n\nWith this setup, we'll be able to update versions of `@elastic/eui` and\n`@elastic/eui-amsterdam` at the same time in a single PR and make use of\nautomated kibana backports. There will be only one set of changes to\nreview by codeowners, and if there are any failing tests when\nbackporting to `8.19` due to, for example, changed color values, we can\nfollow the regular kibana procedures and fix them right in the created\nbackport PR. It'll simplify our workflow quite drastically while keeping\nthe same level of quality.\n\n---------\n\nCo-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>","sha":"ac3fc27a5397456630f974f84bee64f597500b55"}},"sourceBranch":"main","suggestedTargetBranches":["8.19","9.0"],"targetPullRequestStates":[{"branch":"main","label":"v9.1.0","branchLabelMappingKey":"^v9.1.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/219818","number":219818,"mergeCommit":{"message":"Add conditional switching between EUI releases (#219818)\n\n## Summary\n\nThis PR simplifies the weekly EUI upgrade and backport process by\nconditionally aliasing `@elastic/eui` in shared deps webpack\nconfigurations.\n\n# Backstory\n\nThe EUI team (@elastic/eui-team) is responsible for keeping EUI up to\ndate in Kibana. Historically, this has been a relatively straightforward\n(yet time-consuming) process, however, due to `8.x` backport\ncomplexities caused by it using a different theme, it has become way\nmore demanding on everybody involved.\n\nEUI is released on weekly basis. Each week, we release official EUI\nversions tagged `latest` in npmjs and get a PR open that updates the\npackage in kibana `main`.\n\nOur upgrade PRs tend to require anywhere between 2 and 25 codeowner\nreviews due to the number of snapshots we need to update while working\non the EUI upgrade PRs. These snapshot changes are 99% of the time\nharmless, yet it still takes 2+ full workdays to ping teams and get all\nreviews necessary to get the PR merged. Generally speaking, we aim to\nhave the upgrade PR open on Monday and merged by Friday.\n\n## The issue with `8.x` backports\n\nKibana 8.x uses the Amsterdam theme instead of Borealis, which is used\nin Kibana 9.0 and up. To keep 8.x up to date, for each official EUI\nrelease we prepare another special Kibana 8.x only release of EUI (e.g.,\n`101.2.0-amsterdam.0`). These special releases have the theme hardcoded\nto Amsterdam at compile-time to avoid any initial theme errors Kibana\ncould otherwise experience. This is done primarily because some areas in\nKibana read EUI theme values outside of React components, and we have no\nstable way to determine what the active theme is since there's no\ncontext information. This is where we need to fall back to Amsterdam in\n8.x and Borealis in 9.x.\n\n**Since there are two different EUI versions - one for Kibana `main` and\n9.0, and another for 8.x branches, we cannot use the automated backports\nfeature**. Instead, we open two separate PRs and configure backport\nlabels accordingly. Having two PRs is far from ideal since codeowners\nneed to review our changes twice, and we're more likely to make\nmistakes.\n\n# Our proposal\n\nFollowing the recently introduced React version switching logic, we want\nto conditionally switch between two `@elastic/eui` releases depending on\nthe kibana branch/version while keeping automated backports possible.\n\nTo achieve that, I added a dependency alias `@elastic/eui-amsterdam`\nthat points to the Amsterdam EUI release and configured `resolve.alias`\nin shared deps to resolve the correct dependency based on the optional\n`EUI_AMSTERDAM` environment variable. When this change is merged to\n`main` and backported to `9.0` and `8.19`, I'll open a follow-up PR to\nthe `8.19` branch updating the default value of `EUI_AMSTERDAM` to\n`\"true\"`. This should result in no conflicts and be easy to follow.\n\nSince 8.19 [uses the Amsterdam release of\n`@elastic/eui`](https://github.com/elastic/kibana/blob/8.19/package.json#L126)\n(e.g., `101.2.0-amsterdam.0`), there's no risk backporting this PR as-is\nwithout `EUI_AMSTERDAM` configured beforehand.\n\n## What does it change?\n\nWith this setup, we'll be able to update versions of `@elastic/eui` and\n`@elastic/eui-amsterdam` at the same time in a single PR and make use of\nautomated kibana backports. There will be only one set of changes to\nreview by codeowners, and if there are any failing tests when\nbackporting to `8.19` due to, for example, changed color values, we can\nfollow the regular kibana procedures and fix them right in the created\nbackport PR. It'll simplify our workflow quite drastically while keeping\nthe same level of quality.\n\n---------\n\nCo-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>","sha":"ac3fc27a5397456630f974f84bee64f597500b55"}},{"branch":"8.19","label":"v8.19.0","branchLabelMappingKey":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"},{"branch":"9.0","label":"v9.0.3","branchLabelMappingKey":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"}]}] BACKPORT-->
kibanamachine
added
the
backport missing
Contributor
|
Looks like this PR has backport PRs but they still haven't been merged. Please merge them ASAP to keep the branches relatively in sync. |
tkajtoch
added a commit
that referenced
this pull request
May 30, 2025
# Backport This will backport the following commits from `main` to `9.0`: - [Add conditional switching between EUI releases (#219818)](#219818) <!--- Backport version: 10.0.0 --> ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sorenlouv/backport) <!--BACKPORT [{"author":{"name":"Tomasz Kajtoch","email":"tomasz.kajtoch@elastic.co"},"sourceCommit":{"committedDate":"2025-05-28T13:41:19Z","message":"Add conditional switching between EUI releases (#219818)\n\n## Summary\n\nThis PR simplifies the weekly EUI upgrade and backport process by\nconditionally aliasing `@elastic/eui` in shared deps webpack\nconfigurations.\n\n# Backstory\n\nThe EUI team (@elastic/eui-team) is responsible for keeping EUI up to\ndate in Kibana. Historically, this has been a relatively straightforward\n(yet time-consuming) process, however, due to `8.x` backport\ncomplexities caused by it using a different theme, it has become way\nmore demanding on everybody involved.\n\nEUI is released on weekly basis. Each week, we release official EUI\nversions tagged `latest` in npmjs and get a PR open that updates the\npackage in kibana `main`.\n\nOur upgrade PRs tend to require anywhere between 2 and 25 codeowner\nreviews due to the number of snapshots we need to update while working\non the EUI upgrade PRs. These snapshot changes are 99% of the time\nharmless, yet it still takes 2+ full workdays to ping teams and get all\nreviews necessary to get the PR merged. Generally speaking, we aim to\nhave the upgrade PR open on Monday and merged by Friday.\n\n## The issue with `8.x` backports\n\nKibana 8.x uses the Amsterdam theme instead of Borealis, which is used\nin Kibana 9.0 and up. To keep 8.x up to date, for each official EUI\nrelease we prepare another special Kibana 8.x only release of EUI (e.g.,\n`101.2.0-amsterdam.0`). These special releases have the theme hardcoded\nto Amsterdam at compile-time to avoid any initial theme errors Kibana\ncould otherwise experience. This is done primarily because some areas in\nKibana read EUI theme values outside of React components, and we have no\nstable way to determine what the active theme is since there's no\ncontext information. This is where we need to fall back to Amsterdam in\n8.x and Borealis in 9.x.\n\n**Since there are two different EUI versions - one for Kibana `main` and\n9.0, and another for 8.x branches, we cannot use the automated backports\nfeature**. Instead, we open two separate PRs and configure backport\nlabels accordingly. Having two PRs is far from ideal since codeowners\nneed to review our changes twice, and we're more likely to make\nmistakes.\n\n# Our proposal\n\nFollowing the recently introduced React version switching logic, we want\nto conditionally switch between two `@elastic/eui` releases depending on\nthe kibana branch/version while keeping automated backports possible.\n\nTo achieve that, I added a dependency alias `@elastic/eui-amsterdam`\nthat points to the Amsterdam EUI release and configured `resolve.alias`\nin shared deps to resolve the correct dependency based on the optional\n`EUI_AMSTERDAM` environment variable. When this change is merged to\n`main` and backported to `9.0` and `8.19`, I'll open a follow-up PR to\nthe `8.19` branch updating the default value of `EUI_AMSTERDAM` to\n`\"true\"`. This should result in no conflicts and be easy to follow.\n\nSince 8.19 [uses the Amsterdam release of\n`@elastic/eui`](https://github.com/elastic/kibana/blob/8.19/package.json#L126)\n(e.g., `101.2.0-amsterdam.0`), there's no risk backporting this PR as-is\nwithout `EUI_AMSTERDAM` configured beforehand.\n\n## What does it change?\n\nWith this setup, we'll be able to update versions of `@elastic/eui` and\n`@elastic/eui-amsterdam` at the same time in a single PR and make use of\nautomated kibana backports. There will be only one set of changes to\nreview by codeowners, and if there are any failing tests when\nbackporting to `8.19` due to, for example, changed color values, we can\nfollow the regular kibana procedures and fix them right in the created\nbackport PR. It'll simplify our workflow quite drastically while keeping\nthe same level of quality.\n\n---------\n\nCo-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>","sha":"ac3fc27a5397456630f974f84bee64f597500b55","branchLabelMapping":{"^v9.1.0$":"main","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["release_note:skip","backport:version","v9.1.0","v8.19.0","v9.0.3"],"title":"Add conditional switching between EUI releases","number":219818,"url":"https://github.com/elastic/kibana/pull/219818","mergeCommit":{"message":"Add conditional switching between EUI releases (#219818)\n\n## Summary\n\nThis PR simplifies the weekly EUI upgrade and backport process by\nconditionally aliasing `@elastic/eui` in shared deps webpack\nconfigurations.\n\n# Backstory\n\nThe EUI team (@elastic/eui-team) is responsible for keeping EUI up to\ndate in Kibana. Historically, this has been a relatively straightforward\n(yet time-consuming) process, however, due to `8.x` backport\ncomplexities caused by it using a different theme, it has become way\nmore demanding on everybody involved.\n\nEUI is released on weekly basis. Each week, we release official EUI\nversions tagged `latest` in npmjs and get a PR open that updates the\npackage in kibana `main`.\n\nOur upgrade PRs tend to require anywhere between 2 and 25 codeowner\nreviews due to the number of snapshots we need to update while working\non the EUI upgrade PRs. These snapshot changes are 99% of the time\nharmless, yet it still takes 2+ full workdays to ping teams and get all\nreviews necessary to get the PR merged. Generally speaking, we aim to\nhave the upgrade PR open on Monday and merged by Friday.\n\n## The issue with `8.x` backports\n\nKibana 8.x uses the Amsterdam theme instead of Borealis, which is used\nin Kibana 9.0 and up. To keep 8.x up to date, for each official EUI\nrelease we prepare another special Kibana 8.x only release of EUI (e.g.,\n`101.2.0-amsterdam.0`). These special releases have the theme hardcoded\nto Amsterdam at compile-time to avoid any initial theme errors Kibana\ncould otherwise experience. This is done primarily because some areas in\nKibana read EUI theme values outside of React components, and we have no\nstable way to determine what the active theme is since there's no\ncontext information. This is where we need to fall back to Amsterdam in\n8.x and Borealis in 9.x.\n\n**Since there are two different EUI versions - one for Kibana `main` and\n9.0, and another for 8.x branches, we cannot use the automated backports\nfeature**. Instead, we open two separate PRs and configure backport\nlabels accordingly. Having two PRs is far from ideal since codeowners\nneed to review our changes twice, and we're more likely to make\nmistakes.\n\n# Our proposal\n\nFollowing the recently introduced React version switching logic, we want\nto conditionally switch between two `@elastic/eui` releases depending on\nthe kibana branch/version while keeping automated backports possible.\n\nTo achieve that, I added a dependency alias `@elastic/eui-amsterdam`\nthat points to the Amsterdam EUI release and configured `resolve.alias`\nin shared deps to resolve the correct dependency based on the optional\n`EUI_AMSTERDAM` environment variable. When this change is merged to\n`main` and backported to `9.0` and `8.19`, I'll open a follow-up PR to\nthe `8.19` branch updating the default value of `EUI_AMSTERDAM` to\n`\"true\"`. This should result in no conflicts and be easy to follow.\n\nSince 8.19 [uses the Amsterdam release of\n`@elastic/eui`](https://github.com/elastic/kibana/blob/8.19/package.json#L126)\n(e.g., `101.2.0-amsterdam.0`), there's no risk backporting this PR as-is\nwithout `EUI_AMSTERDAM` configured beforehand.\n\n## What does it change?\n\nWith this setup, we'll be able to update versions of `@elastic/eui` and\n`@elastic/eui-amsterdam` at the same time in a single PR and make use of\nautomated kibana backports. There will be only one set of changes to\nreview by codeowners, and if there are any failing tests when\nbackporting to `8.19` due to, for example, changed color values, we can\nfollow the regular kibana procedures and fix them right in the created\nbackport PR. It'll simplify our workflow quite drastically while keeping\nthe same level of quality.\n\n---------\n\nCo-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>","sha":"ac3fc27a5397456630f974f84bee64f597500b55"}},"sourceBranch":"main","suggestedTargetBranches":["8.19","9.0"],"targetPullRequestStates":[{"branch":"main","label":"v9.1.0","branchLabelMappingKey":"^v9.1.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/219818","number":219818,"mergeCommit":{"message":"Add conditional switching between EUI releases (#219818)\n\n## Summary\n\nThis PR simplifies the weekly EUI upgrade and backport process by\nconditionally aliasing `@elastic/eui` in shared deps webpack\nconfigurations.\n\n# Backstory\n\nThe EUI team (@elastic/eui-team) is responsible for keeping EUI up to\ndate in Kibana. Historically, this has been a relatively straightforward\n(yet time-consuming) process, however, due to `8.x` backport\ncomplexities caused by it using a different theme, it has become way\nmore demanding on everybody involved.\n\nEUI is released on weekly basis. Each week, we release official EUI\nversions tagged `latest` in npmjs and get a PR open that updates the\npackage in kibana `main`.\n\nOur upgrade PRs tend to require anywhere between 2 and 25 codeowner\nreviews due to the number of snapshots we need to update while working\non the EUI upgrade PRs. These snapshot changes are 99% of the time\nharmless, yet it still takes 2+ full workdays to ping teams and get all\nreviews necessary to get the PR merged. Generally speaking, we aim to\nhave the upgrade PR open on Monday and merged by Friday.\n\n## The issue with `8.x` backports\n\nKibana 8.x uses the Amsterdam theme instead of Borealis, which is used\nin Kibana 9.0 and up. To keep 8.x up to date, for each official EUI\nrelease we prepare another special Kibana 8.x only release of EUI (e.g.,\n`101.2.0-amsterdam.0`). These special releases have the theme hardcoded\nto Amsterdam at compile-time to avoid any initial theme errors Kibana\ncould otherwise experience. This is done primarily because some areas in\nKibana read EUI theme values outside of React components, and we have no\nstable way to determine what the active theme is since there's no\ncontext information. This is where we need to fall back to Amsterdam in\n8.x and Borealis in 9.x.\n\n**Since there are two different EUI versions - one for Kibana `main` and\n9.0, and another for 8.x branches, we cannot use the automated backports\nfeature**. Instead, we open two separate PRs and configure backport\nlabels accordingly. Having two PRs is far from ideal since codeowners\nneed to review our changes twice, and we're more likely to make\nmistakes.\n\n# Our proposal\n\nFollowing the recently introduced React version switching logic, we want\nto conditionally switch between two `@elastic/eui` releases depending on\nthe kibana branch/version while keeping automated backports possible.\n\nTo achieve that, I added a dependency alias `@elastic/eui-amsterdam`\nthat points to the Amsterdam EUI release and configured `resolve.alias`\nin shared deps to resolve the correct dependency based on the optional\n`EUI_AMSTERDAM` environment variable. When this change is merged to\n`main` and backported to `9.0` and `8.19`, I'll open a follow-up PR to\nthe `8.19` branch updating the default value of `EUI_AMSTERDAM` to\n`\"true\"`. This should result in no conflicts and be easy to follow.\n\nSince 8.19 [uses the Amsterdam release of\n`@elastic/eui`](https://github.com/elastic/kibana/blob/8.19/package.json#L126)\n(e.g., `101.2.0-amsterdam.0`), there's no risk backporting this PR as-is\nwithout `EUI_AMSTERDAM` configured beforehand.\n\n## What does it change?\n\nWith this setup, we'll be able to update versions of `@elastic/eui` and\n`@elastic/eui-amsterdam` at the same time in a single PR and make use of\nautomated kibana backports. There will be only one set of changes to\nreview by codeowners, and if there are any failing tests when\nbackporting to `8.19` due to, for example, changed color values, we can\nfollow the regular kibana procedures and fix them right in the created\nbackport PR. It'll simplify our workflow quite drastically while keeping\nthe same level of quality.\n\n---------\n\nCo-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>","sha":"ac3fc27a5397456630f974f84bee64f597500b55"}},{"branch":"8.19","label":"v8.19.0","branchLabelMappingKey":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"},{"branch":"9.0","label":"v9.0.3","branchLabelMappingKey":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"}]}] BACKPORT-->
kibanamachine
added
v9.0.2
and removed
backport missing
tkajtoch
added a commit
that referenced
this pull request
Jun 3, 2025
## Summary As a follow-up to #219818 this PR makes Kibana 8.19 default to the Amsterdam variant of EUI when `EUI_AMSTERDAM` environment variable is unset. See the initial PR description for more information. ## QA Ensure Kibana imports all EUI components from `@elastic/eui-amsterdam`. https://github.com/user-attachments/assets/39dddf50-5997-4be6-ac00-1da02fa967dc
zacharyparikh
pushed a commit
to zacharyparikh/kibana
that referenced
this pull request
Jun 4, 2025
## Summary This PR simplifies the weekly EUI upgrade and backport process by conditionally aliasing `@elastic/eui` in shared deps webpack configurations. # Backstory The EUI team (@elastic/eui-team) is responsible for keeping EUI up to date in Kibana. Historically, this has been a relatively straightforward (yet time-consuming) process, however, due to `8.x` backport complexities caused by it using a different theme, it has become way more demanding on everybody involved. EUI is released on weekly basis. Each week, we release official EUI versions tagged `latest` in npmjs and get a PR open that updates the package in kibana `main`. Our upgrade PRs tend to require anywhere between 2 and 25 codeowner reviews due to the number of snapshots we need to update while working on the EUI upgrade PRs. These snapshot changes are 99% of the time harmless, yet it still takes 2+ full workdays to ping teams and get all reviews necessary to get the PR merged. Generally speaking, we aim to have the upgrade PR open on Monday and merged by Friday. ## The issue with `8.x` backports Kibana 8.x uses the Amsterdam theme instead of Borealis, which is used in Kibana 9.0 and up. To keep 8.x up to date, for each official EUI release we prepare another special Kibana 8.x only release of EUI (e.g., `101.2.0-amsterdam.0`). These special releases have the theme hardcoded to Amsterdam at compile-time to avoid any initial theme errors Kibana could otherwise experience. This is done primarily because some areas in Kibana read EUI theme values outside of React components, and we have no stable way to determine what the active theme is since there's no context information. This is where we need to fall back to Amsterdam in 8.x and Borealis in 9.x. **Since there are two different EUI versions - one for Kibana `main` and 9.0, and another for 8.x branches, we cannot use the automated backports feature**. Instead, we open two separate PRs and configure backport labels accordingly. Having two PRs is far from ideal since codeowners need to review our changes twice, and we're more likely to make mistakes. # Our proposal Following the recently introduced React version switching logic, we want to conditionally switch between two `@elastic/eui` releases depending on the kibana branch/version while keeping automated backports possible. To achieve that, I added a dependency alias `@elastic/eui-amsterdam` that points to the Amsterdam EUI release and configured `resolve.alias` in shared deps to resolve the correct dependency based on the optional `EUI_AMSTERDAM` environment variable. When this change is merged to `main` and backported to `9.0` and `8.19`, I'll open a follow-up PR to the `8.19` branch updating the default value of `EUI_AMSTERDAM` to `"true"`. This should result in no conflicts and be easy to follow. Since 8.19 [uses the Amsterdam release of `@elastic/eui`](https://github.com/elastic/kibana/blob/8.19/package.json#L126) (e.g., `101.2.0-amsterdam.0`), there's no risk backporting this PR as-is without `EUI_AMSTERDAM` configured beforehand. ## What does it change? With this setup, we'll be able to update versions of `@elastic/eui` and `@elastic/eui-amsterdam` at the same time in a single PR and make use of automated kibana backports. There will be only one set of changes to review by codeowners, and if there are any failing tests when backporting to `8.19` due to, for example, changed color values, we can follow the regular kibana procedures and fix them right in the created backport PR. It'll simplify our workflow quite drastically while keeping the same level of quality. --------- Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
nickpeihl
pushed a commit
to nickpeihl/kibana
that referenced
this pull request
Jun 12, 2025
## Summary This PR simplifies the weekly EUI upgrade and backport process by conditionally aliasing `@elastic/eui` in shared deps webpack configurations. # Backstory The EUI team (@elastic/eui-team) is responsible for keeping EUI up to date in Kibana. Historically, this has been a relatively straightforward (yet time-consuming) process, however, due to `8.x` backport complexities caused by it using a different theme, it has become way more demanding on everybody involved. EUI is released on weekly basis. Each week, we release official EUI versions tagged `latest` in npmjs and get a PR open that updates the package in kibana `main`. Our upgrade PRs tend to require anywhere between 2 and 25 codeowner reviews due to the number of snapshots we need to update while working on the EUI upgrade PRs. These snapshot changes are 99% of the time harmless, yet it still takes 2+ full workdays to ping teams and get all reviews necessary to get the PR merged. Generally speaking, we aim to have the upgrade PR open on Monday and merged by Friday. ## The issue with `8.x` backports Kibana 8.x uses the Amsterdam theme instead of Borealis, which is used in Kibana 9.0 and up. To keep 8.x up to date, for each official EUI release we prepare another special Kibana 8.x only release of EUI (e.g., `101.2.0-amsterdam.0`). These special releases have the theme hardcoded to Amsterdam at compile-time to avoid any initial theme errors Kibana could otherwise experience. This is done primarily because some areas in Kibana read EUI theme values outside of React components, and we have no stable way to determine what the active theme is since there's no context information. This is where we need to fall back to Amsterdam in 8.x and Borealis in 9.x. **Since there are two different EUI versions - one for Kibana `main` and 9.0, and another for 8.x branches, we cannot use the automated backports feature**. Instead, we open two separate PRs and configure backport labels accordingly. Having two PRs is far from ideal since codeowners need to review our changes twice, and we're more likely to make mistakes. # Our proposal Following the recently introduced React version switching logic, we want to conditionally switch between two `@elastic/eui` releases depending on the kibana branch/version while keeping automated backports possible. To achieve that, I added a dependency alias `@elastic/eui-amsterdam` that points to the Amsterdam EUI release and configured `resolve.alias` in shared deps to resolve the correct dependency based on the optional `EUI_AMSTERDAM` environment variable. When this change is merged to `main` and backported to `9.0` and `8.19`, I'll open a follow-up PR to the `8.19` branch updating the default value of `EUI_AMSTERDAM` to `"true"`. This should result in no conflicts and be easy to follow. Since 8.19 [uses the Amsterdam release of `@elastic/eui`](https://github.com/elastic/kibana/blob/8.19/package.json#L126) (e.g., `101.2.0-amsterdam.0`), there's no risk backporting this PR as-is without `EUI_AMSTERDAM` configured beforehand. ## What does it change? With this setup, we'll be able to update versions of `@elastic/eui` and `@elastic/eui-amsterdam` at the same time in a single PR and make use of automated kibana backports. There will be only one set of changes to review by codeowners, and if there are any failing tests when backporting to `8.19` due to, for example, changed color values, we can follow the regular kibana procedures and fix them right in the created backport PR. It'll simplify our workflow quite drastically while keeping the same level of quality. --------- Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
tkajtoch
added a commit
to tkajtoch/kibana
that referenced
this pull request
Aug 27, 2025
This reverts commit ac3fc27.
tkajtoch
added a commit
to tkajtoch/kibana
that referenced
this pull request
Aug 27, 2025
This reverts commit ac3fc27.
delanni
added a commit
to delanni/kibana
that referenced
this pull request
Jan 19, 2026
…c#219818) (elastic#221920)" This reverts commit d7d5e7b.
delanni
added a commit
that referenced
this pull request
Jan 22, 2026
## Summary Revert "[8.19] Add conditional switching between EUI releases (#219818) (#221920)" This reverts commit d7d5e7b. Having 2 dependencies point to the same version of the same dependency on npm seems to wreck yarn's logic, and causes issues on bootstrap. We no longer need this parallel variant of the dependency, so we can just remove it.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
6 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
This PR simplifies the weekly EUI upgrade and backport process by conditionally aliasing
@elastic/euiin shared deps webpack configurations.Backstory
The EUI team (@elastic/eui-team) is responsible for keeping EUI up to date in Kibana. Historically, this has been a relatively straightforward (yet time-consuming) process, however, due to
8.xbackport complexities caused by it using a different theme, it has become way more demanding on everybody involved.EUI is released on weekly basis. Each week, we release official EUI versions tagged
latestin npmjs and get a PR open that updates the package in kibanamain.Our upgrade PRs tend to require anywhere between 2 and 25 codeowner reviews due to the number of snapshots we need to update while working on the EUI upgrade PRs. These snapshot changes are 99% of the time harmless, yet it still takes 2+ full workdays to ping teams and get all reviews necessary to get the PR merged. Generally speaking, we aim to have the upgrade PR open on Monday and merged by Friday.
The issue with
8.xbackportsKibana 8.x uses the Amsterdam theme instead of Borealis, which is used in Kibana 9.0 and up. To keep 8.x up to date, for each official EUI release we prepare another special Kibana 8.x only release of EUI (e.g.,
101.2.0-amsterdam.0). These special releases have the theme hardcoded to Amsterdam at compile-time to avoid any initial theme errors Kibana could otherwise experience. This is done primarily because some areas in Kibana read EUI theme values outside of React components, and we have no stable way to determine what the active theme is since there's no context information. This is where we need to fall back to Amsterdam in 8.x and Borealis in 9.x.Since there are two different EUI versions - one for Kibana
mainand 9.0, and another for 8.x branches, we cannot use the automated backports feature. Instead, we open two separate PRs and configure backport labels accordingly. Having two PRs is far from ideal since codeowners need to review our changes twice, and we're more likely to make mistakes.Our proposal
Following the recently introduced React version switching logic, we want to conditionally switch between two
@elastic/euireleases depending on the kibana branch/version while keeping automated backports possible.To achieve that, I added a dependency alias
@elastic/eui-amsterdamthat points to the Amsterdam EUI release and configuredresolve.aliasin shared deps to resolve the correct dependency based on the optionalEUI_AMSTERDAMenvironment variable. When this change is merged tomainand backported to9.0and8.19, I'll open a follow-up PR to the8.19branch updating the default value ofEUI_AMSTERDAMto"true". This should result in no conflicts and be easy to follow.Since 8.19 uses the Amsterdam release of
@elastic/eui(e.g.,101.2.0-amsterdam.0), there's no risk backporting this PR as-is withoutEUI_AMSTERDAMconfigured beforehand.What does it change?
With this setup, we'll be able to update versions of
@elastic/euiand@elastic/eui-amsterdamat the same time in a single PR and make use of automated kibana backports. There will be only one set of changes to review by codeowners, and if there are any failing tests when backporting to8.19due to, for example, changed color values, we can follow the regular kibana procedures and fix them right in the created backport PR. It'll simplify our workflow quite drastically while keeping the same level of quality.