chore(envs): migrate react components to react-env@2.0.0 by davidfirst · Pull Request #10467 · teambit/bit

davidfirst · 2026-07-06T15:29:40Z

Migrate the workspace's React components from the legacy core teambit.react/react env to teambit.react/react-env@2.0.0 (React 19, Rspack, Oxlint).

The large pnpm-lock.yaml diff is the expected dependency churn from React 18→19 and the webpack→rspack / eslint→oxlint toolchain switch.

qodo-free-for-open-source-projects · 2026-07-06T15:31:13Z

PR Summary by Qodo

Migrate Bit React components to teambit.react/react-env@2.0.0

✨ Enhancement ⚙️ Configuration changes 🕐 40+ Minutes

AI Description

• Switch workspace React components to teambit.react/react-env@2.0.0 (React 19, Rspack, Oxlint).
• Persist env assignment per component via .bitmap config entries.
• Regenerate pnpm-lock.yaml for the React/toolchain dependency churn.

Diagram

graph TD
  W(["Bit workspace"]) --> B[".bitmap component config"] --> E(["react-env@2.0.0"]) --> R(["Rspack build"])
  E --> O(["Oxlint lint"])
  W --> L["pnpm-lock.yaml"] --> D(["React 19 deps"])

High-Level Assessment

The following are alternative approaches to this PR:

1. Workspace-level env via variants (workspace.jsonc)

➕ Avoids large .bitmap churn by applying env by path/pattern
➕ Easier to keep future migrations centralized
➕ Makes env intent visible in a single config file
➖ May not cover components needing per-component overrides
➖ Requires confidence that variants match all intended component roots

2. Introduce a custom env extending react-env@2.0.0

➕ Centralizes future tweaks (Rspack/Oxlint overrides) without touching every component
➕ Provides a stable internal env name/version for the workspace
➖ Adds a maintained env component/package
➖ May be unnecessary if react-env v2 defaults are sufficient

3. Incremental migration (subset of components / lane-by-lane)

➕ Reduces blast radius; easier to bisect regressions
➕ Allows verifying React 19/toolchain changes on critical surfaces first
➖ Temporary inconsistency across components/environments
➖ Longer migration window and more coordination overhead

Recommendation: If the workspace expects to keep all React components on the same env, prefer a workspace variant (or a thin custom env) to minimize per-component .bitmap edits over time. If per-component env pinning is required for this repo’s workflow, the current approach is acceptable—review should focus on ensuring all intended components received the env config and that the lockfile aligns with React 19 + Rspack/Oxlint.

Files changed (2) +34078 / -16040

Other (2) +34078 / -16040

.bitmapAssign react-env@2.0.0 to many React components +427/-61

Assign react-env@2.0.0 to many React components

• Adds per-component config blocks referencing teambit.react/react-env@2.0.0 and sets teambit.envs/envs env to teambit.react/react-env. This persists the env migration at the component metadata level for a large set of components.

.bitmap

pnpm-lock.yamlUpdate lockfile for React 19 + Rspack/Oxlint dependency churn +33651/-15979

Update lockfile for React 19 + Rspack/Oxlint dependency churn
• Regenerates the pnpm lockfile to reflect updated React (18→19) and toolchain dependency graph changes introduced by moving to react-env v2.
pnpm-lock.yaml

qodo-free-for-open-source-projects · 2026-07-06T15:41:01Z

Code Review by Qodo

🐞 Bugs (2) 📘 Rule violations (0) 📜 Skill insights (0)

1. React 18 not overridden 🐞 Bug ≡ Correctness ⭐ New

Description

The overrides added in workspace.jsonc only pin react/react-dom for majors 17 and 19, but the
lockfile still includes react@18.3.1 and even react-dom@19.2.7 resolved in a react@18.3.1 context.
Because peerDependencyRules.allowAny includes react/react-dom, pnpm can keep these incompatible
pairings, defeating the stated “single React version” goal and risking runtime/rendering issues in
capsules.

Code

workspace.jsonc[R712-720]

+      // Collapse react/react-dom to a single version in capsules. Published components pull a
+      // range of react versions (17.0.2, 19.1.0, 19.2.0); without this, @teambit/logger resolves
+      // into multiple pnpm variants (e.g. _react@19.1.0 and _react@19.2.7) whose Logger types are
+      // incompatible (TS2345 "separate declarations of a private property 'extensionName'") and the
+      // build fails. react-env@2.0.0 uses 19.2.7, so standardize every react major on it.
+      "react@17": "19.2.7",
+      "react-dom@17": "19.2.7",
+      "react@19": "19.2.7",
+      "react-dom@19": "19.2.7",

Evidence

The override block standardizes only majors 17 and 19, while the PR branch lockfile still contains
React 18 and explicitly includes a ReactDOM 19 + React 18 resolution context; additionally, the
workspace config allows peer mismatches for react/react-dom, so these broken pairings can persist
rather than failing the install.

workspace.jsonc[693-720]
workspace.jsonc[737-748]
pnpm-lock.yaml[49230-49236]
pnpm-lock.yaml[112695-112715]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`workspace.jsonc` claims to standardize “every react major” on 19.2.7, but the override list only covers 17 and 19. In the PR branch lockfile, React 18 remains and some dependency contexts resolve `react-dom@19.2.7` alongside `react@18.3.1`, which is an incompatible pairing.

## Issue Context
- The workspace config explicitly allows peer mismatches for `react`/`react-dom` via `peerDependencyRules.allowAny`, so pnpm won’t necessarily block these combinations.
- The PR’s intent is to migrate to `react-env@2.0.0` (React 19), so leaving React 18 in the graph and/or allowing cross-major ReactDOM pairings undermines the migration.

## Fix Focus Areas
- workspace.jsonc[693-720]
- workspace.jsonc[737-748]
- pnpm-lock.yaml[49230-49236]
- pnpm-lock.yaml[112695-112715]

## Suggested fix
1. Extend the overrides to also cover React 18, e.g. add:
  - `"react@18": "19.2.7"`
  - `"react-dom@18": "19.2.7"`
  (or otherwise ensure React 18 cannot be selected anywhere in capsules).
2. Re-run installation to regenerate `pnpm-lock.yaml`.
3. Verify the lockfile no longer contains:
  - `react@18.x`
  - `react-dom@19.x(react@18.x)` (and other cross-major pairings)
  and that capsules resolve a single consistent React/ReactDOM pair.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

2. Missing env migration 🐞 Bug ≡ Correctness

Description

ui/highlighter-provider is a React TSX component but it was not updated in .bitmap to use
teambit.react/react-env@2.0.0 / teambit.envs/envs, unlike adjacent React UI components. Without
explicit env configuration, Bit will resolve its env implicitly (via other aspects/defaults), which
can lead to inconsistent build/lint/preview behavior compared to the rest of the migrated React UI
components.

Code

.bitmap[R2151-2152]

  "ui/highlighter-provider": {
      "name": "ui/highlighter-provider",

Evidence

In .bitmap, ui/error-fallback has the new env config but the next React UI component
ui/highlighter-provider does not, even though its source is a React TSX component. Bit’s env
resolution code shows that when teambit.envs/envs isn’t configured, the env is derived implicitly
from other aspects or defaults, so this component can diverge from the intended migrated env.

.bitmap[2139-2157]
scopes/react/ui/highlighter-provider/highlighter-provider.tsx[1-4]
scopes/envs/envs/environments.main.runtime.ts[640-649]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`ui/highlighter-provider` is a React component (TSX) but is missing the new `teambit.react/react-env@2.0.0` and `teambit.envs/envs` configuration in `.bitmap`, so it won't be pinned to the migrated React env like other UI components.
## Issue Context
Other React UI components in the same area of `.bitmap` were updated to include:
- `"teambit.react/react-env@2.0.0": {}`
- `"teambit.envs/envs": { "env": "teambit.react/react-env" }`
Bit will otherwise calculate the env implicitly when `teambit.envs/envs` is not configured.
## Fix Focus Areas
- .bitmap[2151-2157]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Previous review results

Review updated until commit 729e964

Results up to commit d937038

🐞 Bugs (1) 📘 Rule violations (0) 📜 Skill insights (0)

1. Missing env migration 🐞 Bug ≡ Correctness

Description

ui/highlighter-provider is a React TSX component but it was not updated in .bitmap to use
teambit.react/react-env@2.0.0 / teambit.envs/envs, unlike adjacent React UI components. Without
explicit env configuration, Bit will resolve its env implicitly (via other aspects/defaults), which
can lead to inconsistent build/lint/preview behavior compared to the rest of the migrated React UI
components.

Code

.bitmap[R2151-2152]

   "ui/highlighter-provider": {
       "name": "ui/highlighter-provider",

Evidence

In .bitmap, ui/error-fallback has the new env config but the next React UI component
ui/highlighter-provider does not, even though its source is a React TSX component. Bit’s env
resolution code shows that when teambit.envs/envs isn’t configured, the env is derived implicitly
from other aspects or defaults, so this component can diverge from the intended migrated env.

.bitmap[2139-2157]
scopes/react/ui/highlighter-provider/highlighter-provider.tsx[1-4]
scopes/envs/envs/environments.main.runtime.ts[640-649]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`ui/highlighter-provider` is a React component (TSX) but is missing the new `teambit.react/react-env@2.0.0` and `teambit.envs/envs` configuration in `.bitmap`, so it won't be pinned to the migrated React env like other UI components.
## Issue Context
Other React UI components in the same area of `.bitmap` were updated to include:
- `"teambit.react/react-env@2.0.0": {}`
- `"teambit.envs/envs": { "env": "teambit.react/react-env" }`
Bit will otherwise calculate the env implicitly when `teambit.envs/envs` is not configured.
## Fix Focus Areas
- .bitmap[2151-2157]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Results up to commit 0910c88

🐞 Bugs (1) 📘 Rule violations (0) 📜 Skill insights (0)

1. Missing env migration 🐞 Bug ≡ Correctness

Description

ui/highlighter-provider is a React TSX component but it was not updated in .bitmap to use
teambit.react/react-env@2.0.0 / teambit.envs/envs, unlike adjacent React UI components. Without
explicit env configuration, Bit will resolve its env implicitly (via other aspects/defaults), which
can lead to inconsistent build/lint/preview behavior compared to the rest of the migrated React UI
components.

Code

.bitmap[R2151-2152]

    "ui/highlighter-provider": {
        "name": "ui/highlighter-provider",

Evidence

In .bitmap, ui/error-fallback has the new env config but the next React UI component
ui/highlighter-provider does not, even though its source is a React TSX component. Bit’s env
resolution code shows that when teambit.envs/envs isn’t configured, the env is derived implicitly
from other aspects or defaults, so this component can diverge from the intended migrated env.

.bitmap[2139-2157]
scopes/react/ui/highlighter-provider/highlighter-provider.tsx[1-4]
scopes/envs/envs/environments.main.runtime.ts[640-649]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`ui/highlighter-provider` is a React component (TSX) but is missing the new `teambit.react/react-env@2.0.0` and `teambit.envs/envs` configuration in `.bitmap`, so it won't be pinned to the migrated React env like other UI components.

## Issue Context
Other React UI components in the same area of `.bitmap` were updated to include:
- `"teambit.react/react-env@2.0.0": {}`
- `"teambit.envs/envs": { "env": "teambit.react/react-env" }`

Bit will otherwise calculate the env implicitly when `teambit.envs/envs` is not configured.

## Fix Focus Areas
- .bitmap[2151-2157]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Results up to commit e349e23

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0)

Great, no issues found!

Qodo reviewed your code and found no material issues that require review

qodo-free-for-open-source-projects · 2026-07-06T18:16:56Z

Code review by qodo was updated up to the latest commit 0910c88

qodo-free-for-open-source-projects · 2026-07-06T19:15:46Z

Code review by qodo was updated up to the latest commit d937038

The migration to react-env@2.0.0 (react 19.2.7) left the workspace pinned to react 19.1.0, so @teambit/logger built as two incompatible pnpm variants (_react@19.1.0 vs _react@19.2.7) whose LoggerMain types don't unify, failing the capsule build with hundreds of cascading TS errors. Pin react/react-dom to 19.2.7 and add react@19/react-dom@19 overrides to collapse every react major onto a single version.

qodo-free-for-open-source-projects · 2026-07-06T19:55:41Z

Code review by qodo was updated up to the latest commit 729e964

chore(envs): migrate react components to react-env@2.0.0

e349e23

Merge remote-tracking branch 'origin/master' into migrate-react-env-v2

0910c88

qodo-free-for-open-source-projects Bot reviewed Jul 6, 2026

View reviewed changes

Comment thread .bitmap

Merge branch 'master' into migrate-react-env-v2

d937038

qodo-free-for-open-source-projects Bot reviewed Jul 6, 2026

View reviewed changes

Comment thread workspace.jsonc

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

chore(envs): migrate react components to react-env@2.0.0#10467

chore(envs): migrate react components to react-env@2.0.0#10467
davidfirst wants to merge 4 commits into
masterfrom
migrate-react-env-v2

davidfirst commented Jul 6, 2026

Uh oh!

qodo-free-for-open-source-projects Bot commented Jul 6, 2026

Uh oh!

qodo-free-for-open-source-projects Bot commented Jul 6, 2026 •

edited

Loading

Great, no issues found!

Uh oh!

Uh oh!

qodo-free-for-open-source-projects Bot commented Jul 6, 2026

Uh oh!

qodo-free-for-open-source-projects Bot commented Jul 6, 2026

Uh oh!

Uh oh!

qodo-free-for-open-source-projects Bot commented Jul 6, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Conversation

davidfirst commented Jul 6, 2026

Uh oh!

qodo-free-for-open-source-projects Bot commented Jul 6, 2026

PR Summary by Qodo

Uh oh!

qodo-free-for-open-source-projects Bot commented Jul 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Code Review by Qodo

Previous review results

Great, no issues found!

Uh oh!

Uh oh!

qodo-free-for-open-source-projects Bot commented Jul 6, 2026

Uh oh!

qodo-free-for-open-source-projects Bot commented Jul 6, 2026

Uh oh!

Uh oh!

qodo-free-for-open-source-projects Bot commented Jul 6, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

qodo-free-for-open-source-projects Bot commented Jul 6, 2026 •

edited

Loading