chore: update node babel/mocha envs by davidfirst · Pull Request #10477 · teambit/bit

davidfirst · 2026-07-09T14:25:40Z

Updates the node envs to their latest versions via bit env update, scoped to just these two:

node-babel-mocha → 1.0.2 (drops the ESLint stack for oxlint, pre-bundled preview, @mdx-js/react v3)
node-typescript-mocha → 1.0.1

…-mocha 1.0.1, core-aspect-env 1.0.1)

qodo-free-for-open-source-projects · 2026-07-09T14:26:41Z

PR Summary by Qodo

chore: pin updated Bit env versions in .bitmap

⚙️ Configuration changes 🕐 20-40 Minutes

AI Description

• Upgrade core Bit envs to latest versions for consistent tooling.
• Make env assignment explicit per component in .bitmap to avoid implicit resolution.
• Pin React env usage for affected UI components (teambit.react/v17/react-env@1.2.7).

Diagram

graph TD
  WS["Bit workspace"] --> BM[".bitmap"] --> C["Components (many)"]
  BM --> E1(("node-babel-mocha@1.0.2")) --> C
  BM --> E2(("node-typescript-mocha@1.0.1")) --> C
  BM --> E3(("core-aspect-env@1.0.1")) --> C
  BM --> E4(("react-env@1.2.7")) --> C
  subgraph Legend
    direction LR
    _file[["File"]] ~~~ _env(("Env")) ~~~ _cmp["Components/Modules"]
  end

High-Level Assessment

The following are alternative approaches to this PR:

1. Rely on implicit env resolution (no per-component config blocks)

➕ Much smaller diffs and less churn in .bitmap
➕ Fewer merge conflicts in a frequently-touched file
➖ Less reproducible: env selection can change with upstream defaults
➖ Harder to audit which tooling version a component uses

2. Pin envs via workspace-level defaults/variants (instead of per-component pins)

➕ Centralized configuration, potentially smaller .bitmap footprint
➕ Easier bulk updates when policy is 'most components share the same env'
➖ May not capture exceptions cleanly (components needing different envs)
➖ Still risks implicit behavior if some components fall outside variants

Recommendation: Keep the PR’s approach (explicit, version-pinned env entries) because it maximizes determinism and makes toolchain changes auditable. If .bitmap churn becomes a recurring pain, consider moving more of this policy to workspace-level variants while keeping explicit pins for exceptions.

Files changed (1) +896 / -224

Other (1) +896 / -224

.bitmapPin updated env versions and make per-component env config explicit +896/-224

Pin updated env versions and make per-component env config explicit

• Adds explicit 'config' entries across many components to pin the env and version they use. Updates the pinned core env versions to 'node-babel-mocha@1.0.2', 'node-typescript-mocha@1.0.1', and 'core-aspect-env@1.0.1', and pins 'teambit.react/v17/react-env@1.2.7' for several UI components.

.bitmap

qodo-free-for-open-source-projects · 2026-07-09T14:30:21Z

Code Review by Qodo

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

1. Lockfile env version drift 🐞 Bug ☼ Reliability

Description

.bitmap now pins components to node-babel-mocha@1.0.2 / node-typescript-mocha@1.0.1, but
pnpm-lock.yaml still resolves @teambit/node.envs.node-babel-mocha@1.0.1 and
@teambit/node.envs.node-typescript-mocha@1.0.0. This makes installs non-reproducible and can lead
to builds/capsules using the old env (or failing to resolve the intended env version).

Code

.bitmap[R17-20]

+        "rootDir": "components/legacy/analytics",
+        "config": {
+            "teambit.node/envs/node-babel-mocha@1.0.2": {}
+        }

Evidence
The PR pins env versions in .bitmap, but the lockfile still contains only older resolved env
package versions, meaning the workspace dependency resolution is out of sync with the configured env
versions.
.bitmap[12-21]
.bitmap[550-558]
pnpm-lock.yaml[9499-9506]
pnpm-lock.yaml[10501-10506]
pnpm-lock.yaml[36232-36236]

Agent prompt

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

## Issue description
`.bitmap` references `teambit.node/envs/node-babel-mocha@1.0.2` and `teambit.node/envs/node-typescript-mocha@1.0.1`, but `pnpm-lock.yaml` still resolves the previous env package versions (babel: 1.0.1, typescript: 1.0.0). This can cause CI/local installs to not actually use the updated environments, and may trigger resolution/runtime errors when Bit expects the newer env artifacts.
### Issue Context
These envs are installed as `.bit_roots` packages, so the lockfile must include the updated `.bit_roots/...@<version>` entries and the corresponding `@teambit/node.envs.*@<version>` entries.
### Fix Focus Areas
- .bitmap[12-21]
- .bitmap[550-558]
- pnpm-lock.yaml[9499-9506]
- pnpm-lock.yaml[10501-10506]
- pnpm-lock.yaml[36232-36236]
### Suggested fix
1. Regenerate the lockfile by running the repo’s standard install flow after the env update (commonly `bit install` and/or `pnpm install` depending on how this workspace manages `.bit_roots`).
2. Verify `pnpm-lock.yaml` includes:
- `.bit_roots/teambit.node_envs_node-babel-mocha@1.0.2`
- `.bit_roots/teambit.node_envs_node-typescript-mocha@1.0.1`
- `@teambit/node.envs.node-babel-mocha@1.0.2`
- `@teambit/node.envs.node-typescript-mocha@1.0.1`
3. Commit the updated `pnpm-lock.yaml`.

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

2. Window access during render 🐞 Bug ≡ Correctness

Description

useCurrentUser() reads window.location.href in the effect dependency array, which is evaluated
during render and will throw when window is undefined (Node/SSR/tests). This becomes more likely
to break builds/tests now that the component is explicitly configured in .bitmap with the
node-babel-mocha@1.0.2 environment.

Code

.bitmap[R892-895]

+        "rootDir": "scopes/cloud/hooks/use-current-user",
+        "config": {
+            "teambit.node/envs/node-babel-mocha@1.0.2": {}
+        }

Evidence
.bitmap shows hooks/use-current-user now has the Node env configured, and the hook code
dereferences window.location.href in the dependency array, which is evaluated immediately during
render and will crash when window is unavailable.
.bitmap[887-896]
scopes/cloud/hooks/use-current-user/use-current-user.ts[24-39]
scopes/workspace/install/install.main.runtime.ts[1380-1386]

Agent prompt

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

## Issue description
`scopes/cloud/hooks/use-current-user/use-current-user.ts` evaluates `window.location.href` during render time via the effect dependency array (`[window.location.href]`). In non-browser contexts, this throws `ReferenceError: window is not defined`.
### Issue Context
This component is explicitly configured in `.bitmap` to use `teambit.node/envs/node-babel-mocha@1.0.2`, increasing the likelihood it will be executed in Node-based contexts (capsule tests/build tooling).
### Fix Focus Areas
- .bitmap[887-896]
- scopes/cloud/hooks/use-current-user/use-current-user.ts[24-39]
### Suggested fix
Refactor to avoid reading `window` during render:
- Compute a safe dependency value:
- `const href = typeof window === 'undefined' ? '' : window.location.href;`
- Use `href` in the dependency array.
Or, if you only need to set redirect once:
- Guard and run once:
- `React.useEffect(() => { if (typeof window === 'undefined') return; ... }, []);`
(Choose the behavior that matches the intended redirect-update semantics.)

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

3. Stale global loader registry 🐞 Bug ☼ Reliability

Description

WorkspaceConfig.workspaceConfigLoadingRegistry is now stored on globalThis, but
loadBit.clearGlobalsIfNeeded() can early-return without clearing it; this allows a loader function
bound to an older ConfigMain instance to persist and be used by Consumer.load() /
LegacyWorkspaceConfig.loadIfExist(), returning cached/stale legacy workspace config for the same
workspace path.

Code

components/legacy/consumer-config/workspace-config.ts[R47-52]

+  static get workspaceConfigLoadingRegistry(): WorkspaceConfigLoadFunction | undefined {
+    return (globalThis as any)[workspaceConfigLoadingRegistryKey];
+  }
+  static set workspaceConfigLoadingRegistry(func: WorkspaceConfigLoadFunction | undefined) {
+    (globalThis as any)[workspaceConfigLoadingRegistryKey] = func;
+  }

Evidence
The registry is now process-global via globalThis; ConfigMain.provider() registers a closure
that can return cached legacy config for a matching workspace path, and Consumer.load() relies on
this mechanism. However, loadBit.clearGlobalsIfNeeded() can skip clearing all legacy globals
entirely due to its early-return condition, so the global loader can persist across in-process
loadBit() runs.
components/legacy/consumer-config/workspace-config.ts[32-52]
components/legacy/consumer-config/workspace-config.ts[113-122]
scopes/harmony/config/config.main.runtime.ts[126-151]
components/legacy/consumer/consumer.ts[487-505]
scopes/harmony/bit/load-bit.ts[337-353]

Agent prompt

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

## Issue description
`workspaceConfigLoadingRegistry` is now persisted on `globalThis`, so it can survive module duplication (intended), but it also becomes a true process-global that can survive between multiple in-process `loadBit()` calls when `clearGlobalsIfNeeded()` returns early. When this happens, `LegacyWorkspaceConfig.loadIfExist()` can invoke a loader closure bound to a previous `ConfigMain`, which may return cached config for matching paths.
### Issue Context
- The loader is registered from `ConfigMain.provider()` and may return the already-loaded legacy config for the same `dirPath` (without re-reading files).
- `Consumer.load()` depends on `LegacyWorkspaceConfig.loadIfExist()`.
- `loadBit.clearGlobalsIfNeeded()` currently decides whether to clear global registries based only on `loadConsumer.cache` and `PackageJsonTransformer.packageJsonTransformersRegistry.length`.
### Fix Focus Areas
- scopes/harmony/bit/load-bit.ts[343-353]
- scopes/harmony/config/config.main.runtime.ts[126-151]
- components/legacy/consumer-config/workspace-config.ts[32-52]
- components/legacy/consumer/consumer.ts[487-505]
### Suggested fix
1) Update `clearGlobalsIfNeeded()` to also consider (and clear) `LegacyWorkspaceConfig.workspaceConfigLoadingRegistry` (and/or remove the early-return and always clear the snapshot list).
2) Optionally, when clearing the registry, delete the `globalThis` key (not just set it to `undefined`) to avoid lingering global properties and to allow GC of the old closure.

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

4. ~~Missing EOF newline~~ ✓ Resolved 🐞 Bug ⚙ Maintainability

Description

.bitmap ends without a trailing newline, which can cause noisy diffs and occasional
tooling/formatter edge cases when processing the file.

Code

.bitmap[R2860-2861]
"$schema-version": "17.0.0"
}

Evidence

The file terminates at the closing brace with no additional line break afterwards, indicating a
missing trailing newline.

.bitmap[2858-2861]

Agent prompt

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

## Issue description
`.bitmap` is missing a trailing newline at EOF.
### Issue Context
Some tools and diff/patch workflows expect text files to end with a newline; lacking it can create noisy diffs and edge-case parsing/concatenation issues.
### Fix Focus Areas
- .bitmap[2860-2861]

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

qodo-free-for-open-source-projects · 2026-07-09T14:32:02Z

Code Review by Qodo

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

Great, no issues found!

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

…breaks TS compile)

qodo-free-for-open-source-projects · 2026-07-09T15:09:25Z

Code review by qodo was updated up to the latest commit 8fa4087

… & react-env@1.2.7 bumps (TS5095 in preview/compile)

qodo-free-for-open-source-projects · 2026-07-09T15:53:55Z

Code review by qodo was updated up to the latest commit 99762e8

qodo-free-for-open-source-projects · 2026-07-10T14:32:25Z

Code review by qodo was updated up to the latest commit 9b3cd66

qodo-free-for-open-source-projects · 2026-07-10T15:51:35Z

+        "rootDir": "components/legacy/analytics",
+        "config": {
+            "teambit.node/envs/node-babel-mocha@1.0.2": {}
+        }


1. Lockfile env version drift 🐞 Bug ☼ Reliability

.bitmap now pins components to node-babel-mocha@1.0.2 / node-typescript-mocha@1.0.1, but pnpm-lock.yaml still resolves @teambit/node.envs.node-babel-mocha@1.0.1 and @teambit/node.envs.node-typescript-mocha@1.0.0. This makes installs non-reproducible and can lead to builds/capsules using the old env (or failing to resolve the intended env version).

Agent Prompt

### Issue description `.bitmap` references `teambit.node/envs/node-babel-mocha@1.0.2` and `teambit.node/envs/node-typescript-mocha@1.0.1`, but `pnpm-lock.yaml` still resolves the previous env package versions (babel: 1.0.1, typescript: 1.0.0). This can cause CI/local installs to not actually use the updated environments, and may trigger resolution/runtime errors when Bit expects the newer env artifacts. ### Issue Context These envs are installed as `.bit_roots` packages, so the lockfile must include the updated `.bit_roots/...@<version>` entries and the corresponding `@teambit/node.envs.*@<version>` entries. ### Fix Focus Areas - .bitmap[12-21] - .bitmap[550-558] - pnpm-lock.yaml[9499-9506] - pnpm-lock.yaml[10501-10506] - pnpm-lock.yaml[36232-36236] ### Suggested fix 1. Regenerate the lockfile by running the repo’s standard install flow after the env update (commonly `bit install` and/or `pnpm install` depending on how this workspace manages `.bit_roots`). 2. Verify `pnpm-lock.yaml` includes: - `.bit_roots/teambit.node_envs_node-babel-mocha@1.0.2` - `.bit_roots/teambit.node_envs_node-typescript-mocha@1.0.1` - `@teambit/node.envs.node-babel-mocha@1.0.2` - `@teambit/node.envs.node-typescript-mocha@1.0.1` 3. Commit the updated `pnpm-lock.yaml`.

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

qodo-free-for-open-source-projects · 2026-07-10T15:51:35Z

+        "rootDir": "scopes/cloud/hooks/use-current-user",
+        "config": {
+            "teambit.node/envs/node-babel-mocha@1.0.2": {}
+        }


2. Window access during render 🐞 Bug ≡ Correctness

useCurrentUser() reads window.location.href in the effect dependency array, which is evaluated during render and will throw when window is undefined (Node/SSR/tests). This becomes more likely to break builds/tests now that the component is explicitly configured in .bitmap with the node-babel-mocha@1.0.2 environment.

Agent Prompt

### Issue description `scopes/cloud/hooks/use-current-user/use-current-user.ts` evaluates `window.location.href` during render time via the effect dependency array (`[window.location.href]`). In non-browser contexts, this throws `ReferenceError: window is not defined`. ### Issue Context This component is explicitly configured in `.bitmap` to use `teambit.node/envs/node-babel-mocha@1.0.2`, increasing the likelihood it will be executed in Node-based contexts (capsule tests/build tooling). ### Fix Focus Areas - .bitmap[887-896] - scopes/cloud/hooks/use-current-user/use-current-user.ts[24-39] ### Suggested fix Refactor to avoid reading `window` during render: - Compute a safe dependency value: - `const href = typeof window === 'undefined' ? '' : window.location.href;` - Use `href` in the dependency array. Or, if you only need to set redirect once: - Guard and run once: - `React.useEffect(() => { if (typeof window === 'undefined') return; ... }, []);` (Choose the behavior that matches the intended redirect-update semantics.)

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

qodo-free-for-open-source-projects · 2026-07-10T15:51:37Z

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

qodo-free-for-open-source-projects · 2026-07-10T16:32:22Z

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

qodo-free-for-open-source-projects · 2026-07-10T18:00:10Z

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

… duplicate module copies in capsules

qodo-free-for-open-source-projects · 2026-07-10T18:47:35Z

+  static get workspaceConfigLoadingRegistry(): WorkspaceConfigLoadFunction | undefined {
+    return (globalThis as any)[workspaceConfigLoadingRegistryKey];
+  }
+  static set workspaceConfigLoadingRegistry(func: WorkspaceConfigLoadFunction | undefined) {
+    (globalThis as any)[workspaceConfigLoadingRegistryKey] = func;
+  }


1. Stale global loader registry 🐞 Bug ☼ Reliability

WorkspaceConfig.workspaceConfigLoadingRegistry is now stored on globalThis, but loadBit.clearGlobalsIfNeeded() can early-return without clearing it; this allows a loader function bound to an older ConfigMain instance to persist and be used by Consumer.load() / LegacyWorkspaceConfig.loadIfExist(), returning cached/stale legacy workspace config for the same workspace path.

Agent Prompt

### Issue description `workspaceConfigLoadingRegistry` is now persisted on `globalThis`, so it can survive module duplication (intended), but it also becomes a true process-global that can survive between multiple in-process `loadBit()` calls when `clearGlobalsIfNeeded()` returns early. When this happens, `LegacyWorkspaceConfig.loadIfExist()` can invoke a loader closure bound to a previous `ConfigMain`, which may return cached config for matching paths. ### Issue Context - The loader is registered from `ConfigMain.provider()` and may return the already-loaded legacy config for the same `dirPath` (without re-reading files). - `Consumer.load()` depends on `LegacyWorkspaceConfig.loadIfExist()`. - `loadBit.clearGlobalsIfNeeded()` currently decides whether to clear global registries based only on `loadConsumer.cache` and `PackageJsonTransformer.packageJsonTransformersRegistry.length`. ### Fix Focus Areas - scopes/harmony/bit/load-bit.ts[343-353] - scopes/harmony/config/config.main.runtime.ts[126-151] - components/legacy/consumer-config/workspace-config.ts[32-52] - components/legacy/consumer/consumer.ts[487-505] ### Suggested fix 1) Update `clearGlobalsIfNeeded()` to also consider (and clear) `LegacyWorkspaceConfig.workspaceConfigLoadingRegistry` (and/or remove the early-return and always clear the snapshot list). 2) Optionally, when clearing the registry, delete the `globalThis` key (not just set it to `undefined`) to avoid lingering global properties and to allow GC of the old closure.

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

qodo-free-for-open-source-projects · 2026-07-10T18:47:36Z

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

chore: update envs to latest (node-babel-mocha 1.0.2, node-typescript…

1ee3761

…-mocha 1.0.1, core-aspect-env 1.0.1)

ci: sync core-aspect-env cache key to 1.0.1

c73d413

fix: drop react-env@1.2.7 pins from env update (1.2.7 not TS6-ready, …

8fa4087

…breaks TS compile)

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

View reviewed changes

Comment thread .bitmap

fix: scope env update to node envs only; revert core-aspect-env@1.0.1…

99762e8

… & react-env@1.2.7 bumps (TS5095 in preview/compile)

davidfirst changed the title ~~chore: update envs to latest versions~~ chore: update node babel/mocha envs Jul 9, 2026

Merge branch 'master' into chore/update-node-envs

9b3cd66

GiladShoham approved these changes Jul 10, 2026

View reviewed changes

davidfirst enabled auto-merge (squash) July 10, 2026 14:36

Merge branch 'master' into chore/update-node-envs

b25c4be

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

View reviewed changes

Merge branch 'master' into chore/update-node-envs

f1525bd

fix: resolve lint error and capsule declaration-compile type mismatch

abe353e

fix: store workspace-config loading registry on globalThis to survive…

b55288e

… duplicate module copies in capsules

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

View reviewed changes

davidfirst merged commit bc50d7f into master Jul 10, 2026
13 checks passed

davidfirst deleted the chore/update-node-envs branch July 10, 2026 19:27

Uh oh!

Conversation

davidfirst commented Jul 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

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

PR Summary by Qodo

Uh oh!

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

Uh oh!

Code Review by Qodo

Uh oh!

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

Code Review by Qodo

Great, no issues found!

Uh oh!

Uh oh!

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

Uh oh!

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

Uh oh!

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

Uh oh!

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

Choose a reason for hiding this comment

Uh oh!

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

Choose a reason for hiding this comment

Uh oh!

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

Uh oh!

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

Uh oh!

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

Uh oh!

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

Choose a reason for hiding this comment

Uh oh!

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

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

davidfirst commented Jul 9, 2026 •

edited

Loading

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

edited

Loading