Repository navigation
Move color palette functions to @elastic/eui-theme-common to make them individually importable - #10247
Move color palette functions to @elastic/eui-theme-common to make them individually importable#10247sphilipse wants to merge 12 commits into
Conversation
Makes euiPaletteColorBlind and the other palette functions individually importable without loading the whole @elastic/eui package. Kibana server code needs the palettes (pure, chroma-js based) but a single import of the @elastic/eui barrel loads 1,100+ modules of React components into the Node.js server process. - colorPalette and the euiPalette* functions move to @elastic/eui-theme-common, next to the vis color store they read from; the original modules in @elastic/eui re-export them unchanged, so the public API of @elastic/eui is unaffected (including types). - Store initialization moves with them: the vis color store previously got its default colors from @elastic/eui importing @elastic/eui-theme-borealis; now @elastic/eui-theme-borealis initializes the store with its default colors on import (getInstance is idempotent), so palettes work when only the theme packages are loaded. EuiVisColorStore.getInstance() without arguments now throws a descriptive error if the store was never initialized. - React hooks (useEuiPalette*) stay in @elastic/eui. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The color-palettes docs page renders PropTable from docgen output, which only scanned @elastic/eui/src. With the palette implementations moved to @elastic/eui-theme-common, euiPaletteColorBlind disappeared from dist/services/color and static site generation crashed on /docs/utilities/color-palettes/. eui-docgen now runs a second pass over @elastic/eui-theme-common, emitting under dist/eui-theme-common/, and the page imports the palette definitions from there. Output shape is unchanged (verified: all 13 palette functions emitted with the same displayName/path/extends/props structure). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This reverts commit 05015f9.
The color-palettes docs page renders PropTables from docgen data generated from @elastic/eui/src; bare re-exports of the moved palette functions dropped them from that output and broke the docs build. Wrap the @elastic/eui-theme-common implementations in thin, JSDoc'd functions with the original signatures so docgen keeps emitting them (verified locally: euiPaletteColorBlind present again with all six props). No API change. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Removed comments about the implementation location and re-export.
There was a problem hiding this comment.
🟡 Changes recommended
Removing the color-store dependency leaves default colors uninitialized for fresh deep imports, causing palette calls and visualization_colors module evaluation to throw unless explicit colors or a prior theme import are present.
1 open issue
What changed in this PR
Moves palette utilities into @elastic/eui-theme-common so consumers such as Kibana server code can use them without loading the full EUI package.
Changes:
- Relocates palette implementations and types, retaining EUI wrappers and compatibility exports.
- Initializes the visualization color store on Borealis import and adds an error for access before initialization.
- Documents the changes in all three affected packages.
| File | Description |
|---|---|
packages/eui/src/services/color/eui_palettes.ts |
Wraps relocated functions while retaining docblocks. |
packages/eui/src/services/color/color_palette.ts |
Re-exports the shared interpolation utility and constant. |
packages/eui/changelogs/upcoming/10247.md |
Documents relocation and initialization changes. |
packages/eui-theme-common/src/services/vis_color_store.ts |
Allows argument-free access after initialization. |
packages/eui-theme-common/src/services/index.ts |
Exports the palette utilities. |
packages/eui-theme-common/src/services/eui_palettes.ts |
Houses palette implementations with lazy store access. |
packages/eui-theme-common/src/services/color_palette.ts |
Houses the color interpolation implementation. |
packages/eui-theme-common/changelogs/upcoming/10247.md |
Documents new exports and store behavior. |
packages/eui-theme-borealis/src/index.ts |
Initializes the store with default visualization colors. |
packages/eui-theme-borealis/changelogs/upcoming/10247.md |
Documents initialization on import. |
Review effort: Balanced
- @elastic/eui eui_palettes.ts side-effect-imports ./vis_color_store again, so a standalone deep import of the module (and the eager VISUALIZATION_COLORS evaluation in services/color) initializes the vis color store with theme defaults exactly as before the palette move. - Add vis color store tests for the new initialization contract: getInstance() before init throws descriptively, no-argument getInstance() after init returns the existing instance, palettes resolve default colors once a theme initializes the store, and palette calls without any theme loaded throw. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
💚 Build Succeeded
History
|
💚 Build Succeeded
History
|
Kibana Regression Integration TestStatus: 💚 Kibana CI passed |
| // Initializes the vis color store with theme defaults, as importing this | ||
| // module always has; without it a standalone deep import of this module (or | ||
| // evaluating VISUALIZATION_COLORS before a theme loads) would throw. | ||
| import './vis_color_store'; |
There was a problem hiding this comment.
🤖 there's a concern I couldn't confirm about this file being dropped by bundlers in some cases (not in Kibana that bundles all of EUI)
the suggested fix is adding it to sideEffects in package.json
"sideEffects": [
"*.css",
"*.scss",
"**/services/color/vis_color_store.js"
]

Summary
Makes
euiPaletteColorBlindand the othereuiPalette*functions individually importable — without loading the whole@elastic/euipackage — by moving their implementation to@elastic/eui-theme-common.Kibana server code needs the palettes, but
import { euiPaletteColorBlind } from '@elastic/eui'loads the entire EUI codebase. In elastic/kibana#300920 we will remove EUI from the server, but that requires being able to deep import the palettes.The main controversial change is wrapping the palette functions in EUI so we still generate docs for them there.