chore: migrate more aspect-docs components to mdx-env 3.0.3 by GiladShoham · Pull Request #10510 · teambit/bit

GiladShoham · 2026-07-21T12:19:57Z

Bumps several aspect-docs/content components to their latest versions and explicitly pins teambit.mdx/mdx-env@3.0.3 on 21 aspect-docs components (babel, builder, compiler, component, compositions, dependency-resolver, envs, generator, html, logger, etc.), cleaning up remaining places still using the old MDX 1.x env in favor of v3.

qodo-free-for-open-source-projects · 2026-07-21T12:21:33Z

PR Summary by Qodo

Migrate remaining aspect-docs components to mdx-env 3.0.3

⚙️ Configuration changes 🕐 20-40 Minutes

AI Description

• Pin "teambit.mdx/mdx-env@3.0.3" for remaining aspect-docs components via .bitmap.
• Bump aspect-docs/content packages (and react preview) in workspace.jsonc.
• Update pnpm-lock.yaml to reflect the new MDX env and dependency graph.

Diagram

graph TD
  W["workspace.jsonc"] --> D["Docs deps"] --> P["Docs build"]
  B[".bitmap"] --> A["Aspect-docs comps"] --> E(["mdx-env 3.0.3"]) --> P
  L["pnpm-lock.yaml"] --> E
  subgraph Legend
    direction LR
    _f["File"] ~~~ _m["Component group"] ~~~ _d(["Pinned dependency"])
  end

High-Level Assessment

The following are alternative approaches to this PR:

1. Use workspace variants/pattern rules for the mdx-env pin

➕ Less .bitmap churn and fewer per-component entries to maintain
➕ Simpler future roll-forward of mdx-env versions
➖ May not travel with exported components outside this workspace context
➖ Can be harder to trace effective env if multiple variant rules overlap

2. Create a shared aspect-docs base env that pins mdx-env

➕ Single source of truth for docs env configuration
➕ Keeps per-component config minimal
➖ Introduces/maintains an additional base env component
➖ Larger refactor than a migration cleanup PR

Recommendation: Explicit per-component pinning is a pragmatic migration cleanup: it makes the env choice unambiguous and portable with the components. If mdx-env will change often, consider moving to variants or a shared base env later to reduce ongoing maintenance.

Files changed (3) +9815 / -18522

Other (3) +9815 / -18522

.bitmapPin mdx-env@3.0.3 across remaining aspect-docs components +96/-24

Pin mdx-env@3.0.3 across remaining aspect-docs components

• Adds per-component config blocks to explicitly use "teambit.mdx/mdx-env@3.0.3" for many aspect-docs components. Also introduces a few additional per-component env pins (e.g., teambit.node/node@2.0.3 for webpack modules, base React env for a UI provider) to align component environments.

.bitmap

pnpm-lock.yamlRegenerate lockfile for mdx-env migration and dependency bumps +9706/-18485

Regenerate lockfile for mdx-env migration and dependency bumps
• Updates the pnpm lockfile to reflect bumped @teambit/* packages and the pinned MDX env version, ensuring reproducible installs and consistent docs builds.
pnpm-lock.yaml

workspace.jsoncBump aspect-docs/content and preview-related dependencies +13/-13

Bump aspect-docs/content and preview-related dependencies

• Updates multiple @teambit/* aspect-docs/content package versions and bumps @teambit/preview.react-preview to a newer range, aligning the workspace dependency set with the MDX v3 migration.

workspace.jsonc

qodo-free-for-open-source-projects · 2026-07-21T12:27:15Z

Code Review by Qodo

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

1. Caret range enables drift 🐞 Bug ⚙ Maintainability

Description

workspace.jsonc changes @teambit/component.content.component-overview from an exact version to
^1.96.10, which allows future installs/lockfile regenerations to silently pull newer compatible
versions of this docs/content package. This makes future doc/UI behavior changes harder to reproduce
and debug compared to the surrounding exact-pinned 1.96.x content deps.

Code

workspace.jsonc[173]

+        "@teambit/component.content.component-overview": "^1.96.10",

Evidence

The diff introduces a caret range for a content package while neighboring content dependencies
remain pinned to exact versions, indicating inconsistent versioning intent and enabling future
drift. The lockfile shows the currently resolved exact version (1.96.10), reinforcing that using an
exact spec would preserve current behavior deterministically.

workspace.jsonc[154-176]
pnpm-lock.yaml[32049-32062]

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` now specifies `@teambit/component.content.component-overview` with a caret range (`^1.96.10`). Unlike exact version pins, this permits dependency drift when the lockfile is regenerated or when installs occur without a frozen lockfile, potentially changing rendered docs/UI content without an explicit PR.
### Issue Context
Nearby `*.content.*` dependencies are pinned to exact versions (e.g. `@teambit/bit.content.what-is-bit`, `@teambit/compilation.content.compiler-overview`). The lock currently resolves `@teambit/component.content.component-overview@1.96.10`, but the range allows future upgrades.
### Fix Focus Areas
- workspace.jsonc[167-176]

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

2. Versioned core env config 🐞 Bug ☼ Reliability

Description

.bitmap config sets the env for two components to teambit.node/node@2.0.3, but core envs/aspects
are identified by exact unversioned ids (e.g. teambit.node/node). This can cause Bit to treat the
Node env as a non-core aspect id during extension/aspect loading for these components, leading to
incorrect resolution/loading behavior.

Code

.bitmap[R1102-1105]

+        "rootDir": "scopes/webpack/config-mutator",
+        "config": {
+            "teambit.node/node@2.0.3": {}
+        }

Evidence
The repo’s core-aspect/env handling uses unversioned ids and exact-match checks; configuring a core
env with a versioned id prevents it from being recognized/filtered as core during aspect loading.
.bitmap[1097-1106]
.bitmap[1177-1186]
scopes/harmony/bit/manifests.ts[120-176]
scopes/harmony/aspect-loader/aspect-loader.main.runtime.ts[293-334]
scopes/workspace/workspace/workspace-aspects-loader.ts[127-131]
scopes/workspace/workspace/workspace-aspects-loader.ts[755-773]
scopes/workspace/workspace/workspace.ts[2247-2280]
scopes/workspace/workspace/workspace.ts[2441-2447]

Agent prompt

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

## Issue description
Two `.bitmap` component entries configure the Node env as `teambit.node/node@2.0.3`. `teambit.node/node` is a core aspect/env whose core detection and core filtering are based on exact unversioned string ids, so the versioned key bypasses core treatment.
## Issue Context
- `teambit.node/node` is registered as a core aspect.
- Core aspect/env checks are exact string matches.
- During extensions loading, the resolved id string (including version) is passed into `loadAspects()`, which filters core aspects by exact id list, so `...@2.0.3` is not removed.
- Workspace code explicitly documents that core envs must be configured **without** a version.
## Fix Focus Areas
- .bitmap[1097-1106]
- .bitmap[1177-1186]

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

Previous review results

Review updated until commit 65e87d8 ⚖️ Balanced

Results up to commit N/A

🐞 Bugs (2) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. Caret range enables drift 🐞 Bug ⚙ Maintainability

Description

workspace.jsonc changes @teambit/component.content.component-overview from an exact version to
^1.96.10, which allows future installs/lockfile regenerations to silently pull newer compatible
versions of this docs/content package. This makes future doc/UI behavior changes harder to reproduce
and debug compared to the surrounding exact-pinned 1.96.x content deps.

Code

workspace.jsonc[173]

+        "@teambit/component.content.component-overview": "^1.96.10",

Evidence

The diff introduces a caret range for a content package while neighboring content dependencies
remain pinned to exact versions, indicating inconsistent versioning intent and enabling future
drift. The lockfile shows the currently resolved exact version (1.96.10), reinforcing that using an
exact spec would preserve current behavior deterministically.

workspace.jsonc[154-176]
pnpm-lock.yaml[32049-32062]

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` now specifies `@teambit/component.content.component-overview` with a caret range (`^1.96.10`). Unlike exact version pins, this permits dependency drift when the lockfile is regenerated or when installs occur without a frozen lockfile, potentially changing rendered docs/UI content without an explicit PR.
### Issue Context
Nearby `*.content.*` dependencies are pinned to exact versions (e.g. `@teambit/bit.content.what-is-bit`, `@teambit/compilation.content.compiler-overview`). The lock currently resolves `@teambit/component.content.component-overview@1.96.10`, but the range allows future upgrades.
### Fix Focus Areas
- workspace.jsonc[167-176]

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

2. Versioned core env config 🐞 Bug ☼ Reliability

Description

.bitmap config sets the env for two components to teambit.node/node@2.0.3, but core envs/aspects
are identified by exact unversioned ids (e.g. teambit.node/node). This can cause Bit to treat the
Node env as a non-core aspect id during extension/aspect loading for these components, leading to
incorrect resolution/loading behavior.

Code

.bitmap[R1102-1105]

+        "rootDir": "scopes/webpack/config-mutator",
+        "config": {
+            "teambit.node/node@2.0.3": {}
+        }

Evidence
The repo’s core-aspect/env handling uses unversioned ids and exact-match checks; configuring a core
env with a versioned id prevents it from being recognized/filtered as core during aspect loading.
.bitmap[1097-1106]
.bitmap[1177-1186]
scopes/harmony/bit/manifests.ts[120-176]
scopes/harmony/aspect-loader/aspect-loader.main.runtime.ts[293-334]
scopes/workspace/workspace/workspace-aspects-loader.ts[127-131]
scopes/workspace/workspace/workspace-aspects-loader.ts[755-773]
scopes/workspace/workspace/workspace.ts[2247-2280]
scopes/workspace/workspace/workspace.ts[2441-2447]

Agent prompt

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

## Issue description
Two `.bitmap` component entries configure the Node env as `teambit.node/node@2.0.3`. `teambit.node/node` is a core aspect/env whose core detection and core filtering are based on exact unversioned string ids, so the versioned key bypasses core treatment.
## Issue Context
- `teambit.node/node` is registered as a core aspect.
- Core aspect/env checks are exact string matches.
- During extensions loading, the resolved id string (including version) is passed into `loadAspects()`, which filters core aspects by exact id list, so `...@2.0.3` is not removed.
- Workspace code explicitly documents that core envs must be configured **without** a version.
## Fix Focus Areas
- .bitmap[1097-1106]
- .bitmap[1177-1186]

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

qodo-free-for-open-source-projects · 2026-07-21T12:27:16Z

+        "rootDir": "scopes/webpack/config-mutator",
+        "config": {
+            "teambit.node/node@2.0.3": {}
+        }


1. Versioned core env config 🐞 Bug ☼ Reliability

.bitmap config sets the env for two components to teambit.node/node@2.0.3, but core envs/aspects are identified by exact unversioned ids (e.g. teambit.node/node). This can cause Bit to treat the Node env as a non-core aspect id during extension/aspect loading for these components, leading to incorrect resolution/loading behavior.

Agent Prompt

## Issue description Two `.bitmap` component entries configure the Node env as `teambit.node/node@2.0.3`. `teambit.node/node` is a core aspect/env whose core detection and core filtering are based on exact unversioned string ids, so the versioned key bypasses core treatment. ## Issue Context - `teambit.node/node` is registered as a core aspect. - Core aspect/env checks are exact string matches. - During extensions loading, the resolved id string (including version) is passed into `loadAspects()`, which filters core aspects by exact id list, so `...@2.0.3` is not removed. - Workspace code explicitly documents that core envs must be configured **without** a version. ## Fix Focus Areas - .bitmap[1097-1106] - .bitmap[1177-1186]

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

qodo-free-for-open-source-projects · 2026-07-21T14:28:58Z

        "@teambit/component-id": "^1.2.4",
        "@teambit/component-version": "^1.0.4",
-        "@teambit/component.content.component-overview": "1.96.6",
+        "@teambit/component.content.component-overview": "^1.96.10",


1. Caret range enables drift 🐞 Bug ⚙ Maintainability

workspace.jsonc changes @teambit/component.content.component-overview from an exact version to ^1.96.10, which allows future installs/lockfile regenerations to silently pull newer compatible versions of this docs/content package. This makes future doc/UI behavior changes harder to reproduce and debug compared to the surrounding exact-pinned 1.96.x content deps.

Agent Prompt

### Issue description `workspace.jsonc` now specifies `@teambit/component.content.component-overview` with a caret range (`^1.96.10`). Unlike exact version pins, this permits dependency drift when the lockfile is regenerated or when installs occur without a frozen lockfile, potentially changing rendered docs/UI content without an explicit PR. ### Issue Context Nearby `*.content.*` dependencies are pinned to exact versions (e.g. `@teambit/bit.content.what-is-bit`, `@teambit/compilation.content.compiler-overview`). The lock currently resolves `@teambit/component.content.component-overview@1.96.10`, but the range allows future upgrades. ### Fix Focus Areas - workspace.jsonc[167-176]

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

qodo-free-for-open-source-projects · 2026-07-21T14:29:00Z

Code review by qodo was updated up to the latest commit 5bd16b9

qodo-free-for-open-source-projects · 2026-07-21T21:42:12Z

Code Review by Qodo

New Review Started

This review has been superseded by a new analysis

…x-env-migration-cleanup # Conflicts: # pnpm-lock.yaml

qodo-free-for-open-source-projects · 2026-07-21T21:42:58Z

Code Review by Qodo

New Review Started

This review has been superseded by a new analysis

qodo-free-for-open-source-projects · 2026-07-21T21:46:27Z

Code Review by Qodo

New Review Started

This review has been superseded by a new analysis

qodo-free-for-open-source-projects · 2026-07-21T21:57:20Z

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

qodo-free-for-open-source-projects · 2026-07-22T08:06:20Z

Code Review by Qodo

New Review Started

This review has been superseded by a new analysis

…teambit/bit into chore/mdx-env-migration-cleanup

qodo-free-for-open-source-projects · 2026-07-22T08:17:11Z

Code review by qodo was updated up to the latest commit 65e87d8

chore: migrate more aspect-docs components to mdx-env 3.0.3

60b0e72

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

View reviewed changes

bump more stuff to remove mdx 1

5bd16b9

guysaar223 approved these changes Jul 21, 2026

View reviewed changes

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

View reviewed changes

GiladShoham enabled auto-merge (squash) July 21, 2026 14:37

bump mdx env

56ad2a7

Merge branch 'master' of https://github.com/teambit/bit into chore/md…

80240ed

…x-env-migration-cleanup # Conflicts: # pnpm-lock.yaml

update lock file

d09986e

Merge branch 'master' into chore/mdx-env-migration-cleanup

f2a7d74

Merge branch 'master' into chore/mdx-env-migration-cleanup

6e372b0

GiladShoham added 2 commits July 22, 2026 11:07

bump component meta

e9c2d4c

Merge branch 'chore/mdx-env-migration-cleanup' of https://github.com/…

65e87d8

…teambit/bit into chore/mdx-env-migration-cleanup

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

chore: migrate more aspect-docs components to mdx-env 3.0.3#10510

chore: migrate more aspect-docs components to mdx-env 3.0.3#10510
GiladShoham wants to merge 9 commits into
masterfrom
chore/mdx-env-migration-cleanup

GiladShoham commented Jul 21, 2026

Uh oh!

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

Uh oh!

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

edited

Loading

Uh oh!

qodo-free-for-open-source-projects Bot Jul 21, 2026

Uh oh!

qodo-free-for-open-source-projects Bot Jul 21, 2026

Uh oh!

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

Uh oh!

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

edited

Loading

Uh oh!

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

edited

Loading

Uh oh!

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

edited

Loading

Uh oh!

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

Uh oh!

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

edited

Loading

Uh oh!

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

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

GiladShoham commented Jul 21, 2026

Uh oh!

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

PR Summary by Qodo

Uh oh!

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

Uh oh!

Code Review by Qodo

Previous review results

Uh oh!

qodo-free-for-open-source-projects Bot Jul 21, 2026

Choose a reason for hiding this comment

Uh oh!

qodo-free-for-open-source-projects Bot Jul 21, 2026

Choose a reason for hiding this comment

Uh oh!

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

Uh oh!

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

Uh oh!

Code Review by Qodo

New Review Started

Uh oh!

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

Uh oh!

Code Review by Qodo

New Review Started

Uh oh!

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

Uh oh!

Code Review by Qodo

New Review Started

Uh oh!

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

Uh oh!

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

Uh oh!

Code Review by Qodo

New Review Started

Uh oh!

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

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

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

edited

Loading

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

edited

Loading

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

edited

Loading

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

edited

Loading

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

edited

Loading