PR Summary by Qodo

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

✨ Enhancement ⚙️ Configuration changes 🕐 40+ Minutes

• 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.

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"])

Loading

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.

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

Code Review by Qodo

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

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

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

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

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

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

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

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

Great, no issues found!

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

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

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

Superseded by #10642, which does the same migration against the current react-env@2.0.3 on top of latest master.