Skip to content

Build1 publisher3 min readPublished

Kibana upgraded Redux Toolkit by pushing v1 onto an explicit alias

Default package names in the Kibana monorepo now resolve to v2 while roughly 1,100 files import aliased copies of v1, and an ESLint rule scoped to 36 plugin paths keeps the two sets apart until each team opts in.

The Engineer · Build desk

Illustration accompanying Kibana upgraded Redux Toolkit by pushing v1 onto an explicit alias

What happened

  • Kibana's default package names for @reduxjs/toolkit, react-redux and redux now resolve to v2, while the remaining v1 code imports explicit aliases such as redux-toolkit-v1 and react-redux-v7.
  • Roughly 1,100 files moved onto that scheme without any plugin team pausing feature work, with both majors installed in node_modules and separated by npm aliases and webpack module replacement.
  • Redux Toolkit v2 shipped in late 2023, and Elastic says an earlier big-bang attempt at the same upgrade stalled once the real scope of the codebase became clearer.

Compiled by The EngineerSomething wrong?How this is made

Why it matters

  • cost The upgrade's cost turns into config maintenance for whoever owns the build: 36 path entries in a lint rule plus the alias and resolution entries have to stay accurate until the last plugin team migrates.
  • constraint A repo still on React 16 or 17 cannot take this route for react-redux, because React-Redux 9 requires React 18 and no longer carries v8's useSyncExternalStore shim. Kibana was already on React 18.
  • decision Each plugin team now picks its own migration date. Security Solution's 300-plus mixed files can sit on v1 for as long as they need to without blocking anyone else's release.
  • capability New code that imports the default package names gets v2 without anyone deciding to migrate, so the v1 footprint stops growing while teams work through it.

Four plugin families that never adopted Redux Toolkit had to change their imports anyway. Canvas, Maps, Index Management and Cross-Cluster Replication still use plain Redux v4, with createStore, combineReducers, applyMiddleware and connect [8]. They do not need an RTK migration at all, and they needed an edit regardless, because the default `redux` package now resolves to v5 and their imports had to move to the `redux-v4` alias [9]. Expressions imports exactly one function from react-redux, shallowEqual, and it still had to change its import path [10].

Enterprise Search and Content Connectors are a different case. They use kea, more than 150 files in Enterprise Search alone, and kea depends on react-redux v7 underneath [11]. The dependency is kea's, not the application code's, so the split is done in the build: webpack externals, yarn resolutions and an ESLint rule keep React Redux v7 and v9 out of each other's way [12].

Most of the aliased footprint sits in two places. Elastic says Security Solution is the largest consumer at more than 300 files, mixing modern RTK with legacy plain Redux patterns [13]. Against roughly 1,100 aliased files, that is at least 27% in one plugin [1]. Add Enterprise Search's 150 and two plugins account for about 41% of the files touched [2].

Copying this pattern requires three things a monorepo happens to have: one lockfile that accepts resolutions, a bundler config you control well enough to do module replacement, and a lint layer that can be scoped to specific paths [12][4]. Kibana's exit route depends on the third one in particular, since a team migrates by deleting its path from the rule's list and switching back to default imports [5].

I think the inverted ordering is the right trade here, because the edits it forces are mechanical and the ones it defers are not. Changing an import specifier to `redux-v4` is a rename. Lens uses stand-alone getDefaultMiddleware and PreloadedState, both removed in v2, and that is real work [18]. In a repo with one application and a handful of Redux consumers I would still alias the new version and flip the default at the end, because the rename bill then falls on far fewer files.

The first attempt at this upgrade used a big-bang approach and stalled once the real scope became clear, according to Elastic's write-up [7]. RTK v2 shipped in late 2023, which the post describes as nearly three years spent a major version behind [6]. The audit that sorted plugins into camps has its own tracking issue, #239863 [21]. For a plugin architecture built on lazy loading, the feature the post singles out is combineSlices with slice reducer injection for code splitting [16].

What to watch

  • Whether Security Solution's 300-plus files come off the alias, and how many of the 36 lint-scoped paths are left when they do.
  • Whether kea ships a release that works with react-redux v9, since Enterprise Search's 150-plus files currently depend on the bundler split.
  • Whether Elastic publishes the webpack externals and yarn resolutions config, which is what a second monorepo would need to copy the pattern.
Loading claim ledger
Loading source directory links
Loading share composer
Loading topic controls
Loading related stories