chore: update typescript to 6.0.3

[davidfirst]

Bumps the repo's own typescript dev dependency from 5.9.2 to 6.0.3 in workspace.jsonc (both the dependency policy and the bvm-root pins), matching the TS6 core envs and typescript-compiler@3.0.0. pnpm-lock.yaml regenerated by bit install.

The root tsconfig.json (used by the tsc --noEmit lint check) needed three TS6 adaptations, kept intentionally minimal to preserve the existing resolution behavior:

• ignoreDeprecations: "6.0" — TS6 turns classic node (node10) resolution into a hard error (TS5107). Kept moduleResolution: node (switching to bundler/nodenext would honor exports and surface source-vs-dist duplicate-identity noise across installed @teambit packages). Revisit before TS7 removes node10.
• types: ["node", "jest"] — TS6 no longer auto-includes node_modules/@types. @types/node still loads via imported node builtins, but jest is only used ambiently in specs, so it must be pinned.
• ts-ambient.d.ts — declare module stubs for side-effect imports whose types ship as .d.cts (reset-css, @mdx-js/loader) and can't be resolved under node10. Component builds resolve them fine via bundler; these only satisfy the root check.

npm run lint (tsc --noEmit + oxlint) passes clean; bit install compiles all 313 components.

[qodo-free-for-open-source-projects]

PR Summary by Qodo

chore: bump TypeScript to 6.0.3 and adapt root typecheck config

⚙️ Configuration changes ✨ Enhancement 🕐 20-40 Minutes

AI Description

• Bump repo TypeScript dev dependency from 5.9.2 to 6.0.3 (policy + pins).
• Adapt root tsconfig for TS6 deprecation handling and explicit ambient types.
• Add ambient module stubs to keep root tsc --noEmit passing under node10 resolution.

Diagram

graph TD
  W["workspace.jsonc"] --> TS["TypeScript 6.0.3"] --> L["pnpm-lock.yaml"]
  W --> CFG["tsconfig.json"] --> TSC["tsc --noEmit (lint)"]
  AMB["ts-ambient.d.ts"] --> CFG
  BIT["bit component builds"] --> TS

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Use a separate tsconfig for root `tsc --noEmit` (bundler/nodenext)

• ➕ Avoids relying on deprecated node10 resolution for the root check
• ➕ May eliminate the need for ignoreDeprecations and some ambient stubs
• ➕ Lets component builds and root lint check converge on modern resolution rules
• ➖ May surface a large amount of exports-map/source-vs-dist identity noise immediately
• ➖ Higher migration cost; could turn into a wide refactor rather than a dependency bump

2. Migrate root config from `moduleResolution: node` to `bundler`/`nodenext` now

• ➕ Aligns with TS direction and improves correctness around exports
• ➕ Reduces future upgrade friction (TS7 removal of node10)
• ➖ Potentially large break surface across installed @teambit packages
• ➖ Risk of needing follow-up PRs to resolve duplicate-type identity and resolution changes

3. Replace ambient stubs with proper type packages or package-level typings

• ➕ Improves type fidelity for reset-css and @mdx-js/loader imports
• ➕ Reduces risk of stubs masking real typing issues
• ➖ Not always feasible if upstream only ships .d.cts in a way incompatible with node10 resolution
• ➖ May require deeper packaging/tooling changes beyond the scope of this upgrade

Recommendation: Keep the PR’s minimal-compat approach for the TS6 bump (silencing TS5107, explicitly pinning ambient types, and adding narrow stubs) to avoid a broad resolution migration. Consider a follow-up to introduce a dedicated lint tsconfig using bundler/nodenext once the repo is ready to absorb exports-map-driven resolution changes.

Files changed (4) +775 / -1713

Other (4) +775 / -1713

pnpm-lock.yamlRegenerate lockfile for TypeScript 6.0.3 +752/-1710

Regenerate lockfile for TypeScript 6.0.3

• Updates the pnpm lockfile to reflect the TypeScript version bump and the resulting dependency graph changes produced by the install step.

pnpm-lock.yaml

ts-ambient.d.tsAdd ambient module stubs for side-effect-only imports +7/-0

Add ambient module stubs for side-effect-only imports

• Introduces 'declare module' stubs for packages whose typings ship as '.d.cts' and are not resolvable by the root 'tsc --noEmit' check under classic node10 resolution. This is scoped to unblocking the root typecheck without changing component build behavior.

ts-ambient.d.ts

tsconfig.jsonMake root tsconfig TS6-compatible without changing resolution semantics +14/-1

Make root tsconfig TS6-compatible without changing resolution semantics

• Adds 'ignoreDeprecations: "6.0"' to keep using classic 'moduleResolution: node' under TS6, and explicitly sets 'types: ["node", "jest"]' due to TS6 no longer auto-including 'node_modules/@types'. Includes the new ambient declarations file in the root typecheck.

tsconfig.json

workspace.jsoncBump TypeScript from 5.9.2 to 6.0.3 in dependency policy and pins +2/-2

Bump TypeScript from 5.9.2 to 6.0.3 in dependency policy and pins

• Updates the workspace dependency policy entry for 'typescript' and the pinned version used in the toolchain configuration to 6.0.3 to match the TS6 environment expectations.

workspace.jsonc

[qodo-free-for-open-source-projects]

Code Review by Qodo

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

1. TS5 still installed 🐞 Bug ☼ Reliability ⭐ New

Description

Even after bumping the workspace dependency policy to TypeScript 6.0.3, pnpm-lock.yaml still pins
scopes/harmony/bit to typescript@5.9.2, so installs keep multiple TypeScript versions and that
importer can still resolve/use TS5. This can reintroduce TS5-vs-TS6 behavior differences for any
tooling executed in that workspace package (or anything resolving its local typescript).

Code

workspace.jsonc[648]

+        "typescript": "6.0.3",

Evidence

workspace.jsonc pins TypeScript to 6.0.3, and the lockfile shows the root importer using 6.0.3,
but also shows scopes/harmony/bit still depending on 5.9.2 and the presence of a
typescript@5.9.2 package entry—proving TS5 is still installed and tied to that importer.

workspace.jsonc[643-650]
pnpm-lock.yaml[2058-2063]
pnpm-lock.yaml[21753-21880]
pnpm-lock.yaml[49596-49604]

Agent prompt

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

## Issue description
The PR updates `workspace.jsonc` to TypeScript `6.0.3`, but `pnpm-lock.yaml` still records `typescript@5.9.2` as a direct dependency for the `scopes/harmony/bit` workspace importer. This leaves multiple TypeScript versions in the install and may cause some tooling to run under TS5.

## Issue Context
The root importer is already on TS6, so this is a per-importer skew.

## Fix Focus Areas
- pnpm-lock.yaml[2058-2063]
- pnpm-lock.yaml[21753-21880]
- workspace.jsonc[643-650]

## Suggested fix
1. Identify why the `scopes/harmony/bit` importer still requests TS `5.9.2` (component-level dependency policy / variant override / generated manifest input).
2. Update that source to request `typescript@6.0.3`.
3. Regenerate `pnpm-lock.yaml` (e.g., via the same `bit install` workflow used for this PR) and confirm `scopes/harmony/bit` now resolves TS6.

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

---

2. TS5-incompatible CJS tsconfig 🐞 Bug ⚙ Maintainability

Description

Several tsconfig templates now combine moduleResolution: "bundler" with a CommonJS module kind,
including scopes/react/react/typescript/tsconfig.cjs.json (via extending a bundler-based base
config) and the templates in scopes/harmony/aspect/typescript/tsconfig.json and
scopes/typescript/typescript/tsconfig.default.json. The repo’s own e2e notes state TS5 config
readers reject this bundler + CJS pairing (TS5095), so TS5-based tooling consuming these
configs/templates may fail to parse/load them.

Code

scopes/react/react/typescript/tsconfig.json[13]

+    "moduleResolution": "bundler",

Evidence

The cited tsconfig files show the problematic pairing in two ways: the React base env tsconfig now
sets moduleResolution: "bundler" and its CJS variant extends it while overriding module to
CommonJS, and the Harmony/TypeScript templates explicitly set both a CommonJS module and
moduleResolution: "bundler". The e2e comment in e2e/harmony/tsconfig-env-mismatch.e2e.ts
explicitly calls out that TS5 readers reject bundler when paired with a CJS module (TS5095), which
directly matches the configurations present in these files and demonstrates why TS5-based config
loaders would error.

scopes/react/react/typescript/tsconfig.json[1-18]
scopes/react/react/typescript/tsconfig.cjs.json[1-6]
e2e/harmony/tsconfig-env-mismatch.e2e.ts[54-57]
scopes/harmony/aspect/typescript/tsconfig.json[6-24]
scopes/typescript/typescript/tsconfig.default.json[3-20]

Agent prompt

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

## Issue description
Multiple tsconfig templates/configs currently produce an unsupported TypeScript 5 combination: `compilerOptions.moduleResolution: "bundler"` together with a CommonJS module kind (`module: "CommonJS"`/`"commonjs"`). This happens both explicitly (in shared templates) and implicitly (where a CJS tsconfig extends a bundler-based base config), and the repo’s own e2e notes document that TS5 config readers reject this pairing with TS5095—so TS5-based tooling (older tsserver/IDEs or other TS5 config readers) may fail to load/parse these configs.
## Issue Context
- The React env base tsconfig switched to `moduleResolution: "bundler"`, and `scopes/react/react/typescript/tsconfig.cjs.json` extends it while overriding only `module` to `CommonJS`, creating a `bundler + CommonJS` configuration.
- `scopes/harmony/aspect/typescript/tsconfig.json` and `scopes/typescript/typescript/tsconfig.default.json` also now combine CommonJS `module` with `moduleResolution: "bundler"`.
- The repository’s e2e test comments explicitly call out TS5095 rejection for `bundler` + CJS under TS5 readers, establishing this as a known incompatibility pattern.
- These configs/templates appear to be shared/published/consumed by other parts of the system, so TS5 readability may matter even if the repo itself is pinned to TS6.
## Fix Focus Areas
- scopes/react/react/typescript/tsconfig.cjs.json[1-18]
- scopes/react/react/typescript/tsconfig.json[1-18]
- scopes/harmony/aspect/typescript/tsconfig.json[6-24]
- scopes/typescript/typescript/tsconfig.default.json[3-20]
- e2e/harmony/tsconfig-env-mismatch.e2e.ts[54-57]

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

---

3. Ambient stubs widen to any ✓ Resolved 🐞 Bug ≡ Correctness

Description

ts-ambient.d.ts uses bare declare module '…'; stubs, which makes those modules implicitly any
and allows accidental value imports without type errors. This reduces the effectiveness of the root
tsc --noEmit check for catching misuse of reset-css / @mdx-js/loader beyond their intended
side-effect-only usage.

Code

ts-ambient.d.ts[R6-7]

+declare module 'reset-css';
+declare module '@mdx-js/loader';

Evidence

The new ambient file defines the modules without bodies, which in TS declaration files results in
any-typed modules; the codebase contains side-effect imports of both modules, so this ambient
typing directly impacts what the root typecheck will allow for those imports.

ts-ambient.d.ts[1-7]
scopes/scope/scope/ui/scope.tsx[1-4]
scopes/react/react/webpack/webpack.config.base.ts[11-16]

Agent prompt

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

## Issue description
The new `ts-ambient.d.ts` declares `reset-css` and `@mdx-js/loader` with `declare module 'pkg';` which makes them implicitly `any`. That permits accidental value imports (e.g., `import x from 'reset-css'`) to typecheck, even though these modules are intended to be side-effect-only in this repo.
## Issue Context
There are real side-effect imports of these packages in the codebase; the ambient file is included in the root `tsconfig.json` program.
## Fix Focus Areas
- ts-ambient.d.ts[1-7]
### Suggested change
Change the stubs to empty-module declarations so side-effect imports remain valid but value imports are type errors:

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

---

View more (2)

4. Mocha typings excluded 🐞 Bug ≡ Correctness

Description

tsconfig.json now restricts ambient typings to "types": ["node", "jest"], so Mocha’s ambient
declarations (including the this.timeout() context used in e2e tests) are no longer part of the
repo-wide tsc --noEmit program. As a result, e2e tests are type-checked against the wrong
test-runner API and Mocha-only context usage is no longer type-validated.

Code

tsconfig.json[R15-19]

+    // TS6 no longer auto-includes node_modules/@types. `@types/node` still loads
+    // program-wide because node builtins are imported across the repo, but `jest`
+    // globals are only ever used ambiently (never imported), so pin the two ambient
+    // type packages this repo-wide check needs.
+    "types": ["node", "jest"],

Evidence

The root tsconfig limits ambient types to Node+Jest, but e2e tests use Mocha’s this.timeout()
context; Mocha typings exist in the dependency tree but are not loaded under the current types
pin.

tsconfig.json[2-36]
e2e/harmony/compile.e2e.ts[9-11]
pnpm-lock.yaml[39809-39813]

Agent prompt

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

## Issue description
The root `tsconfig.json` pins `compilerOptions.types` to only `node` and `jest`. This excludes Mocha ambient declarations even though the repo’s `e2e/**/*.ts` tests are Mocha-based and use Mocha-only context APIs like `this.timeout()` inside `describe(function () { ... })` callbacks. This makes the repo-wide `tsc --noEmit` check validate those tests against the wrong type environment.
### Issue Context
- Root `tsconfig.json` includes the `e2e` directory.
- Many e2e tests use Mocha’s suite context (`this.timeout(...)`).
- `@types/mocha` is present in the lockfile, but it won’t be loaded when `types` is pinned to only `node` and `jest`.
### Fix Focus Areas
- tsconfig.json[14-20]
### Suggested fix
Update `compilerOptions.types` to include Mocha (or split e2e into a separate tsconfig used by the typecheck):
- Option A (minimal): `"types": ["node", "jest", "mocha"]`
- Option B: Create a dedicated `tsconfig.e2e.json` with `types: ["node","mocha"]` and run `tsc -p tsconfig.e2e.json` as part of lint/typecheck.

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

---

5. Unpinned Jest ambient types 🐞 Bug ☼ Reliability

Description

tsconfig.json now forces loading Jest globals via "types": ["node", "jest"], which requires
@types/jest to be resolvable from the workspace root. workspace.jsonc doesn’t declare/pin
@types/jest, and the lockfile contains multiple @types/jest majors, so the repo-wide typecheck
can become dependent on hoisting/resolution details and can drift across environments.

Code

tsconfig.json[R14-19]

+    "ignoreDeprecations": "6.0",
+    // TS6 no longer auto-includes node_modules/@types. `@types/node` still loads
+    // program-wide because node builtins are imported across the repo, but `jest`
+    // globals are only ever used ambiently (never imported), so pin the two ambient
+    // type packages this repo-wide check needs.
+    "types": ["node", "jest"],

Evidence

The root tsconfig now explicitly requires the jest type package. The workspace policy shown lists
many @types/* entries but not @types/jest, while the lockfile demonstrates multiple
@types/jest versions are present, so the resolved ambient Jest typings can be inconsistent unless
pinned directly.

tsconfig.json[7-20]
workspace.jsonc[375-410]
workspace.jsonc[541-545]
pnpm-lock.yaml[39728-39735]

Agent prompt

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

## Issue description
The root `tsconfig.json` now explicitly includes Jest ambient types via `compilerOptions.types`. This makes the repo-wide `tsc --noEmit` check depend on `@types/jest` being present and consistently resolved at the workspace root.
### Issue Context
`workspace.jsonc` pins many `@types/*` packages (including `@types/mocha`, `@types/node`) but does not pin `@types/jest`. The lockfile shows multiple installed `@types/jest` versions (26/29/30), which increases the chance of inconsistent type behavior depending on which version ends up available at the root.
### Fix Focus Areas
- workspace.jsonc[370-430]
- tsconfig.json[8-20]
- pnpm-lock.yaml[39728-39735]
### Suggested fix
1. Add `@types/jest` to `teambit.dependencies/dependency-resolver.policy.dependencies` in `workspace.jsonc`.
2. Pin it to a version compatible with the workspace Jest version (e.g. align with Jest 29.x if that’s what the repo uses).
3. Regenerate the lockfile after updating the policy (if your workflow requires it).

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

---

Previous review results

Review updated until commit f3c3c17

Results up to commit 9aa0a55

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

1. TS5-incompatible CJS tsconfig 🐞 Bug ⚙ Maintainability

Description

Several tsconfig templates now combine moduleResolution: "bundler" with a CommonJS module kind,
including scopes/react/react/typescript/tsconfig.cjs.json (via extending a bundler-based base
config) and the templates in scopes/harmony/aspect/typescript/tsconfig.json and
scopes/typescript/typescript/tsconfig.default.json. The repo’s own e2e notes state TS5 config
readers reject this bundler + CJS pairing (TS5095), so TS5-based tooling consuming these
configs/templates may fail to parse/load them.

Code

scopes/react/react/typescript/tsconfig.json[13]

+    "moduleResolution": "bundler",

Evidence

The cited tsconfig files show the problematic pairing in two ways: the React base env tsconfig now
sets moduleResolution: "bundler" and its CJS variant extends it while overriding module to
CommonJS, and the Harmony/TypeScript templates explicitly set both a CommonJS module and
moduleResolution: "bundler". The e2e comment in e2e/harmony/tsconfig-env-mismatch.e2e.ts
explicitly calls out that TS5 readers reject bundler when paired with a CJS module (TS5095), which
directly matches the configurations present in these files and demonstrates why TS5-based config
loaders would error.

scopes/react/react/typescript/tsconfig.json[1-18]
scopes/react/react/typescript/tsconfig.cjs.json[1-6]
e2e/harmony/tsconfig-env-mismatch.e2e.ts[54-57]
scopes/harmony/aspect/typescript/tsconfig.json[6-24]
scopes/typescript/typescript/tsconfig.default.json[3-20]

Agent prompt

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

## Issue description
Multiple tsconfig templates/configs currently produce an unsupported TypeScript 5 combination: `compilerOptions.moduleResolution: "bundler"` together with a CommonJS module kind (`module: "CommonJS"`/`"commonjs"`). This happens both explicitly (in shared templates) and implicitly (where a CJS tsconfig extends a bundler-based base config), and the repo’s own e2e notes document that TS5 config readers reject this pairing with TS5095—so TS5-based tooling (older tsserver/IDEs or other TS5 config readers) may fail to load/parse these configs.
## Issue Context
- The React env base tsconfig switched to `moduleResolution: "bundler"`, and `scopes/react/react/typescript/tsconfig.cjs.json` extends it while overriding only `module` to `CommonJS`, creating a `bundler + CommonJS` configuration.
- `scopes/harmony/aspect/typescript/tsconfig.json` and `scopes/typescript/typescript/tsconfig.default.json` also now combine CommonJS `module` with `moduleResolution: "bundler"`.
- The repository’s e2e test comments explicitly call out TS5095 rejection for `bundler` + CJS under TS5 readers, establishing this as a known incompatibility pattern.
- These configs/templates appear to be shared/published/consumed by other parts of the system, so TS5 readability may matter even if the repo itself is pinned to TS6.
## Fix Focus Areas
- scopes/react/react/typescript/tsconfig.cjs.json[1-18]
- scopes/react/react/typescript/tsconfig.json[1-18]
- scopes/harmony/aspect/typescript/tsconfig.json[6-24]
- scopes/typescript/typescript/tsconfig.default.json[3-20]
- e2e/harmony/tsconfig-env-mismatch.e2e.ts[54-57]

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

---

2. Ambient stubs widen to any 🐞 Bug ≡ Correctness

Description

ts-ambient.d.ts uses bare declare module '…'; stubs, which makes those modules implicitly any
and allows accidental value imports without type errors. This reduces the effectiveness of the root
tsc --noEmit check for catching misuse of reset-css / @mdx-js/loader beyond their intended
side-effect-only usage.

Code

ts-ambient.d.ts[R6-7]

+declare module 'reset-css';
+declare module '@mdx-js/loader';

Evidence

The new ambient file defines the modules without bodies, which in TS declaration files results in
any-typed modules; the codebase contains side-effect imports of both modules, so this ambient
typing directly impacts what the root typecheck will allow for those imports.

ts-ambient.d.ts[1-7]
scopes/scope/scope/ui/scope.tsx[1-4]
scopes/react/react/webpack/webpack.config.base.ts[11-16]

Agent prompt

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

## Issue description
The new `ts-ambient.d.ts` declares `reset-css` and `@mdx-js/loader` with `declare module 'pkg';` which makes them implicitly `any`. That permits accidental value imports (e.g., `import x from 'reset-css'`) to typecheck, even though these modules are intended to be side-effect-only in this repo.
## Issue Context
There are real side-effect imports of these packages in the codebase; the ambient file is included in the root `tsconfig.json` program.
## Fix Focus Areas
- ts-ambient.d.ts[1-7]
### Suggested change
Change the stubs to empty-module declarations so side-effect imports remain valid but value imports are type errors:

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

---

3. Mocha typings excluded 🐞 Bug ≡ Correctness

Description

tsconfig.json now restricts ambient typings to "types": ["node", "jest"], so Mocha’s ambient
declarations (including the this.timeout() context used in e2e tests) are no longer part of the
repo-wide tsc --noEmit program. As a result, e2e tests are type-checked against the wrong
test-runner API and Mocha-only context usage is no longer type-validated.

Code

tsconfig.json[R15-19]

+    // TS6 no longer auto-includes node_modules/@types. `@types/node` still loads
+    // program-wide because node builtins are imported across the repo, but `jest`
+    // globals are only ever used ambiently (never imported), so pin the two ambient
+    // type packages this repo-wide check needs.
+    "types": ["node", "jest"],

Evidence

The root tsconfig limits ambient types to Node+Jest, but e2e tests use Mocha’s this.timeout()
context; Mocha typings exist in the dependency tree but are not loaded under the current types
pin.

tsconfig.json[2-36]
e2e/harmony/compile.e2e.ts[9-11]
pnpm-lock.yaml[39809-39813]

Agent prompt

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

## Issue description
The root `tsconfig.json` pins `compilerOptions.types` to only `node` and `jest`. This excludes Mocha ambient declarations even though the repo’s `e2e/**/*.ts` tests are Mocha-based and use Mocha-only context APIs like `this.timeout()` inside `describe(function () { ... })` callbacks. This makes the repo-wide `tsc --noEmit` check validate those tests against the wrong type environment.
### Issue Context
- Root `tsconfig.json` includes the `e2e` directory.
- Many e2e tests use Mocha’s suite context (`this.timeout(...)`).
- `@types/mocha` is present in the lockfile, but it won’t be loaded when `types` is pinned to only `node` and `jest`.
### Fix Focus Areas
- tsconfig.json[14-20]
### Suggested fix
Update `compilerOptions.types` to include Mocha (or split e2e into a separate tsconfig used by the typecheck):
- Option A (minimal): `"types": ["node", "jest", "mocha"]`
- Option B: Create a dedicated `tsconfig.e2e.json` with `types: ["node","mocha"]` and run `tsc -p tsconfig.e2e.json` as part of lint/typecheck.

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

---

View more (1)

4. Unpinned Jest ambient types 🐞 Bug ☼ Reliability

Description

tsconfig.json now forces loading Jest globals via "types": ["node", "jest"], which requires
@types/jest to be resolvable from the workspace root. workspace.jsonc doesn’t declare/pin
@types/jest, and the lockfile contains multiple @types/jest majors, so the repo-wide typecheck
can become dependent on hoisting/resolution details and can drift across environments.

Code

tsconfig.json[R14-19]

+    "ignoreDeprecations": "6.0",
+    // TS6 no longer auto-includes node_modules/@types. `@types/node` still loads
+    // program-wide because node builtins are imported across the repo, but `jest`
+    // globals are only ever used ambiently (never imported), so pin the two ambient
+    // type packages this repo-wide check needs.
+    "types": ["node", "jest"],

Evidence

The root tsconfig now explicitly requires the jest type package. The workspace policy shown lists
many @types/* entries but not @types/jest, while the lockfile demonstrates multiple
@types/jest versions are present, so the resolved ambient Jest typings can be inconsistent unless
pinned directly.

tsconfig.json[7-20]
workspace.jsonc[375-410]
workspace.jsonc[541-545]
pnpm-lock.yaml[39728-39735]

Agent prompt

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

## Issue description
The root `tsconfig.json` now explicitly includes Jest ambient types via `compilerOptions.types`. This makes the repo-wide `tsc --noEmit` check depend on `@types/jest` being present and consistently resolved at the workspace root.
### Issue Context
`workspace.jsonc` pins many `@types/*` packages (including `@types/mocha`, `@types/node`) but does not pin `@types/jest`. The lockfile shows multiple installed `@types/jest` versions (26/29/30), which increases the chance of inconsistent type behavior depending on which version ends up available at the root.
### Fix Focus Areas
- workspace.jsonc[370-430]
- tsconfig.json[8-20]
- pnpm-lock.yaml[39728-39735]
### Suggested fix
1. Add `@types/jest` to `teambit.dependencies/dependency-resolver.policy.dependencies` in `workspace.jsonc`.
2. Pin it to a version compatible with the workspace Jest version (e.g. align with Jest 29.x if that’s what the repo uses).
3. Regenerate the lockfile after updating the policy (if your workflow requires it).

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

---

Results up to commit 54da7a9

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

1. TS5-incompatible CJS tsconfig 🐞 Bug ⚙ Maintainability ⭐ New

Description

Several tsconfig templates now combine moduleResolution: "bundler" with a CommonJS module kind,
including scopes/react/react/typescript/tsconfig.cjs.json (via extending a bundler-based base
config) and the templates in scopes/harmony/aspect/typescript/tsconfig.json and
scopes/typescript/typescript/tsconfig.default.json. The repo’s own e2e notes state TS5 config
readers reject this bundler + CJS pairing (TS5095), so TS5-based tooling consuming these
configs/templates may fail to parse/load them.

Code

scopes/react/react/typescript/tsconfig.json[13]

+    "moduleResolution": "bundler",

Evidence

The cited tsconfig files show the problematic pairing in two ways: the React base env tsconfig now
sets moduleResolution: "bundler" and its CJS variant extends it while overriding module to
CommonJS, and the Harmony/TypeScript templates explicitly set both a CommonJS module and
moduleResolution: "bundler". The e2e comment in e2e/harmony/tsconfig-env-mismatch.e2e.ts
explicitly calls out that TS5 readers reject bundler when paired with a CJS module (TS5095), which
directly matches the configurations present in these files and demonstrates why TS5-based config
loaders would error.

scopes/react/react/typescript/tsconfig.json[1-18]
scopes/react/react/typescript/tsconfig.cjs.json[1-6]
e2e/harmony/tsconfig-env-mismatch.e2e.ts[54-57]
scopes/harmony/aspect/typescript/tsconfig.json[6-24]
scopes/typescript/typescript/tsconfig.default.json[3-20]

Agent prompt

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

## Issue description
Multiple tsconfig templates/configs currently produce an unsupported TypeScript 5 combination: `compilerOptions.moduleResolution: "bundler"` together with a CommonJS module kind (`module: "CommonJS"`/`"commonjs"`). This happens both explicitly (in shared templates) and implicitly (where a CJS tsconfig extends a bundler-based base config), and the repo’s own e2e notes document that TS5 config readers reject this pairing with TS5095—so TS5-based tooling (older tsserver/IDEs or other TS5 config readers) may fail to load/parse these configs.

## Issue Context
- The React env base tsconfig switched to `moduleResolution: "bundler"`, and `scopes/react/react/typescript/tsconfig.cjs.json` extends it while overriding only `module` to `CommonJS`, creating a `bundler + CommonJS` configuration.
- `scopes/harmony/aspect/typescript/tsconfig.json` and `scopes/typescript/typescript/tsconfig.default.json` also now combine CommonJS `module` with `moduleResolution: "bundler"`.
- The repository’s e2e test comments explicitly call out TS5095 rejection for `bundler` + CJS under TS5 readers, establishing this as a known incompatibility pattern.
- These configs/templates appear to be shared/published/consumed by other parts of the system, so TS5 readability may matter even if the repo itself is pinned to TS6.

## Fix Focus Areas
- scopes/react/react/typescript/tsconfig.cjs.json[1-18]
- scopes/react/react/typescript/tsconfig.json[1-18]
- scopes/harmony/aspect/typescript/tsconfig.json[6-24]
- scopes/typescript/typescript/tsconfig.default.json[3-20]
- e2e/harmony/tsconfig-env-mismatch.e2e.ts[54-57]

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

---

2. Ambient stubs widen to any 🐞 Bug ≡ Correctness ⭐ New

Description

ts-ambient.d.ts uses bare declare module '…'; stubs, which makes those modules implicitly any
and allows accidental value imports without type errors. This reduces the effectiveness of the root
tsc --noEmit check for catching misuse of reset-css / @mdx-js/loader beyond their intended
side-effect-only usage.

Code

ts-ambient.d.ts[R6-7]

+declare module 'reset-css';
+declare module '@mdx-js/loader';

Evidence

The new ambient file defines the modules without bodies, which in TS declaration files results in
any-typed modules; the codebase contains side-effect imports of both modules, so this ambient
typing directly impacts what the root typecheck will allow for those imports.

ts-ambient.d.ts[1-7]
scopes/scope/scope/ui/scope.tsx[1-4]
scopes/react/react/webpack/webpack.config.base.ts[11-16]

Agent prompt

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

## Issue description
The new `ts-ambient.d.ts` declares `reset-css` and `@mdx-js/loader` with `declare module 'pkg';` which makes them implicitly `any`. That permits accidental value imports (e.g., `import x from 'reset-css'`) to typecheck, even though these modules are intended to be side-effect-only in this repo.

## Issue Context
There are real side-effect imports of these packages in the codebase; the ambient file is included in the root `tsconfig.json` program.

## Fix Focus Areas
- ts-ambient.d.ts[1-7]

### Suggested change
Change the stubs to empty-module declarations so side-effect imports remain valid but value imports are type errors:

```ts
declare module 'reset-css' {}
declare module '@mdx-js/loader' {}
```

(Optionally add a short comment noting the intent: side-effect import only.)

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

---

3. Mocha typings excluded 🐞 Bug ≡ Correctness

Description

tsconfig.json now restricts ambient typings to "types": ["node", "jest"], so Mocha’s ambient
declarations (including the this.timeout() context used in e2e tests) are no longer part of the
repo-wide tsc --noEmit program. As a result, e2e tests are type-checked against the wrong
test-runner API and Mocha-only context usage is no longer type-validated.

Code

tsconfig.json[R15-19]

+    // TS6 no longer auto-includes node_modules/@types. `@types/node` still loads
+    // program-wide because node builtins are imported across the repo, but `jest`
+    // globals are only ever used ambiently (never imported), so pin the two ambient
+    // type packages this repo-wide check needs.
+    "types": ["node", "jest"],

Evidence

The root tsconfig limits ambient types to Node+Jest, but e2e tests use Mocha’s this.timeout()
context; Mocha typings exist in the dependency tree but are not loaded under the current types
pin.

tsconfig.json[2-36]
e2e/harmony/compile.e2e.ts[9-11]
pnpm-lock.yaml[39809-39813]

Agent prompt

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

## Issue description
The root `tsconfig.json` pins `compilerOptions.types` to only `node` and `jest`. This excludes Mocha ambient declarations even though the repo’s `e2e/**/*.ts` tests are Mocha-based and use Mocha-only context APIs like `this.timeout()` inside `describe(function () { ... })` callbacks. This makes the repo-wide `tsc --noEmit` check validate those tests against the wrong type environment.
### Issue Context
- Root `tsconfig.json` includes the `e2e` directory.
- Many e2e tests use Mocha’s suite context (`this.timeout(...)`).
- `@types/mocha` is present in the lockfile, but it won’t be loaded when `types` is pinned to only `node` and `jest`.
### Fix Focus Areas
- tsconfig.json[14-20]
### Suggested fix
Update `compilerOptions.types` to include Mocha (or split e2e into a separate tsconfig used by the typecheck):
- Option A (minimal): `"types": ["node", "jest", "mocha"]`
- Option B: Create a dedicated `tsconfig.e2e.json` with `types: ["node","mocha"]` and run `tsc -p tsconfig.e2e.json` as part of lint/typecheck.

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

---

View more (1)

4. Unpinned Jest ambient types 🐞 Bug ☼ Reliability

Description

tsconfig.json now forces loading Jest globals via "types": ["node", "jest"], which requires
@types/jest to be resolvable from the workspace root. workspace.jsonc doesn’t declare/pin
@types/jest, and the lockfile contains multiple @types/jest majors, so the repo-wide typecheck
can become dependent on hoisting/resolution details and can drift across environments.

Code

tsconfig.json[R14-19]

+    "ignoreDeprecations": "6.0",
+    // TS6 no longer auto-includes node_modules/@types. `@types/node` still loads
+    // program-wide because node builtins are imported across the repo, but `jest`
+    // globals are only ever used ambiently (never imported), so pin the two ambient
+    // type packages this repo-wide check needs.
+    "types": ["node", "jest"],

Evidence

The root tsconfig now explicitly requires the jest type package. The workspace policy shown lists
many @types/* entries but not @types/jest, while the lockfile demonstrates multiple
@types/jest versions are present, so the resolved ambient Jest typings can be inconsistent unless
pinned directly.

tsconfig.json[7-20]
workspace.jsonc[375-410]
workspace.jsonc[541-545]
pnpm-lock.yaml[39728-39735]

Agent prompt

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

## Issue description
The root `tsconfig.json` now explicitly includes Jest ambient types via `compilerOptions.types`. This makes the repo-wide `tsc --noEmit` check depend on `@types/jest` being present and consistently resolved at the workspace root.
### Issue Context
`workspace.jsonc` pins many `@types/*` packages (including `@types/mocha`, `@types/node`) but does not pin `@types/jest`. The lockfile shows multiple installed `@types/jest` versions (26/29/30), which increases the chance of inconsistent type behavior depending on which version ends up available at the root.
### Fix Focus Areas
- workspace.jsonc[370-430]
- tsconfig.json[8-20]
- pnpm-lock.yaml[39728-39735]
### Suggested fix
1. Add `@types/jest` to `teambit.dependencies/dependency-resolver.policy.dependencies` in `workspace.jsonc`.
2. Pin it to a version compatible with the workspace Jest version (e.g. align with Jest 29.x if that’s what the repo uses).
3. Regenerate the lockfile after updating the policy (if your workflow requires it).

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

---

Results up to commit c3c82d7

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

1. Mocha typings excluded 🐞 Bug ≡ Correctness ⭐ New

Description

tsconfig.json now restricts ambient typings to "types": ["node", "jest"], so Mocha’s ambient
declarations (including the this.timeout() context used in e2e tests) are no longer part of the
repo-wide tsc --noEmit program. As a result, e2e tests are type-checked against the wrong
test-runner API and Mocha-only context usage is no longer type-validated.

Code

tsconfig.json[R15-19]

+    // TS6 no longer auto-includes node_modules/@types. `@types/node` still loads
+    // program-wide because node builtins are imported across the repo, but `jest`
+    // globals are only ever used ambiently (never imported), so pin the two ambient
+    // type packages this repo-wide check needs.
+    "types": ["node", "jest"],

Evidence

The root tsconfig limits ambient types to Node+Jest, but e2e tests use Mocha’s this.timeout()
context; Mocha typings exist in the dependency tree but are not loaded under the current types
pin.

tsconfig.json[2-36]
e2e/harmony/compile.e2e.ts[9-11]
pnpm-lock.yaml[39809-39813]

Agent prompt

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

### Issue description
The root `tsconfig.json` pins `compilerOptions.types` to only `node` and `jest`. This excludes Mocha ambient declarations even though the repo’s `e2e/**/*.ts` tests are Mocha-based and use Mocha-only context APIs like `this.timeout()` inside `describe(function () { ... })` callbacks. This makes the repo-wide `tsc --noEmit` check validate those tests against the wrong type environment.

### Issue Context
- Root `tsconfig.json` includes the `e2e` directory.
- Many e2e tests use Mocha’s suite context (`this.timeout(...)`).
- `@types/mocha` is present in the lockfile, but it won’t be loaded when `types` is pinned to only `node` and `jest`.

### Fix Focus Areas
- tsconfig.json[14-20]

### Suggested fix
Update `compilerOptions.types` to include Mocha (or split e2e into a separate tsconfig used by the typecheck):
- Option A (minimal): `"types": ["node", "jest", "mocha"]`
- Option B: Create a dedicated `tsconfig.e2e.json` with `types: ["node","mocha"]` and run `tsc -p tsconfig.e2e.json` as part of lint/typecheck.

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

---

2. Unpinned Jest ambient types 🐞 Bug ☼ Reliability

Description

tsconfig.json now forces loading Jest globals via "types": ["node", "jest"], which requires
@types/jest to be resolvable from the workspace root. workspace.jsonc doesn’t declare/pin
@types/jest, and the lockfile contains multiple @types/jest majors, so the repo-wide typecheck
can become dependent on hoisting/resolution details and can drift across environments.

Code

tsconfig.json[R14-19]

+    "ignoreDeprecations": "6.0",
+    // TS6 no longer auto-includes node_modules/@types. `@types/node` still loads
+    // program-wide because node builtins are imported across the repo, but `jest`
+    // globals are only ever used ambiently (never imported), so pin the two ambient
+    // type packages this repo-wide check needs.
+    "types": ["node", "jest"],

Evidence

The root tsconfig now explicitly requires the jest type package. The workspace policy shown lists
many @types/* entries but not @types/jest, while the lockfile demonstrates multiple
@types/jest versions are present, so the resolved ambient Jest typings can be inconsistent unless
pinned directly.

tsconfig.json[7-20]
workspace.jsonc[375-410]
workspace.jsonc[541-545]
pnpm-lock.yaml[39728-39735]

Agent prompt

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

## Issue description
The root `tsconfig.json` now explicitly includes Jest ambient types via `compilerOptions.types`. This makes the repo-wide `tsc --noEmit` check depend on `@types/jest` being present and consistently resolved at the workspace root.
### Issue Context
`workspace.jsonc` pins many `@types/*` packages (including `@types/mocha`, `@types/node`) but does not pin `@types/jest`. The lockfile shows multiple installed `@types/jest` versions (26/29/30), which increases the chance of inconsistent type behavior depending on which version ends up available at the root.
### Fix Focus Areas
- workspace.jsonc[370-430]
- tsconfig.json[8-20]
- pnpm-lock.yaml[39728-39735]
### Suggested fix
1. Add `@types/jest` to `teambit.dependencies/dependency-resolver.policy.dependencies` in `workspace.jsonc`.
2. Pin it to a version compatible with the workspace Jest version (e.g. align with Jest 29.x if that’s what the repo uses).
3. Regenerate the lockfile after updating the policy (if your workflow requires it).

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

---

Results up to commit 6e18656

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

1. Unpinned Jest ambient types 🐞 Bug ☼ Reliability

Description

tsconfig.json now forces loading Jest globals via "types": ["node", "jest"], which requires
@types/jest to be resolvable from the workspace root. workspace.jsonc doesn’t declare/pin
@types/jest, and the lockfile contains multiple @types/jest majors, so the repo-wide typecheck
can become dependent on hoisting/resolution details and can drift across environments.

Code

tsconfig.json[R14-19]

+    "ignoreDeprecations": "6.0",
+    // TS6 no longer auto-includes node_modules/@types. `@types/node` still loads
+    // program-wide because node builtins are imported across the repo, but `jest`
+    // globals are only ever used ambiently (never imported), so pin the two ambient
+    // type packages this repo-wide check needs.
+    "types": ["node", "jest"],

Evidence

The root tsconfig now explicitly requires the jest type package. The workspace policy shown lists
many @types/* entries but not @types/jest, while the lockfile demonstrates multiple
@types/jest versions are present, so the resolved ambient Jest typings can be inconsistent unless
pinned directly.

tsconfig.json[7-20]
workspace.jsonc[375-410]
workspace.jsonc[541-545]
pnpm-lock.yaml[39728-39735]

Agent prompt

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

### Issue description
The root `tsconfig.json` now explicitly includes Jest ambient types via `compilerOptions.types`. This makes the repo-wide `tsc --noEmit` check depend on `@types/jest` being present and consistently resolved at the workspace root.

### Issue Context
`workspace.jsonc` pins many `@types/*` packages (including `@types/mocha`, `@types/node`) but does not pin `@types/jest`. The lockfile shows multiple installed `@types/jest` versions (26/29/30), which increases the chance of inconsistent type behavior depending on which version ends up available at the root.

### Fix Focus Areas
- workspace.jsonc[370-430]
- tsconfig.json[8-20]
- pnpm-lock.yaml[39728-39735]

### Suggested fix
1. Add `@types/jest` to `teambit.dependencies/dependency-resolver.policy.dependencies` in `workspace.jsonc`.
2. Pin it to a version compatible with the workspace Jest version (e.g. align with Jest 29.x if that’s what the repo uses).
3. Regenerate the lockfile after updating the policy (if your workflow requires it).

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

---

[qodo-free-for-open-source-projects]

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

[qodo-free-for-open-source-projects]

Code review by qodo was updated up to the latest commit 54da7a9

[qodo-free-for-open-source-projects]

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

[qodo-free-for-open-source-projects]

1. Ts5 still installed 🐞 Bug ☼ Reliability

Even after bumping the workspace dependency policy to TypeScript 6.0.3, pnpm-lock.yaml still pins
scopes/harmony/bit to typescript@5.9.2, so installs keep multiple TypeScript versions and that
importer can still resolve/use TS5. This can reintroduce TS5-vs-TS6 behavior differences for any
tooling executed in that workspace package (or anything resolving its local typescript).

Agent Prompt

## Issue description
The PR updates `workspace.jsonc` to TypeScript `6.0.3`, but `pnpm-lock.yaml` still records `typescript@5.9.2` as a direct dependency for the `scopes/harmony/bit` workspace importer. This leaves multiple TypeScript versions in the install and may cause some tooling to run under TS5.

## Issue Context
The root importer is already on TS6, so this is a per-importer skew.

## Fix Focus Areas
- pnpm-lock.yaml[2058-2063]
- pnpm-lock.yaml[21753-21880]
- workspace.jsonc[643-650]

## Suggested fix
1. Identify why the `scopes/harmony/bit` importer still requests TS `5.9.2` (component-level dependency policy / variant override / generated manifest input).
2. Update that source to request `typescript@6.0.3`.
3. Regenerate `pnpm-lock.yaml` (e.g., via the same `bit install` workflow used for this PR) and confirm `scopes/harmony/bit` now resolves TS6.

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

[davidfirst]

Good catch — this is real. teambit.harmony/bit's typescript dep lives in the component model (set via a past bit deps set), not in workspace.jsonc — see the note on the variant's dependency-resolver policy: "Changes here won't affect the actual dependencies … To change a dependency from this list, run bit deps set teambit.harmony/bit <pkg@version>." So the workspace.jsonc bump can't move it, and the importer stays on 5.9.2.

Note the actual CI build already compiles under TS6 (it resolves the root-hoisted typescript@6.0.3; that's what surfaces the TS6 errors), so this is a manifest-consistency gap rather than the current build failure. The correct fix is bit deps set teambit.harmony/bit typescript@6.0.3 + bit install, which we're sequencing as part of the broader TS6 rollout (currently gated on the env-side TS6 migration). Leaving this thread open to track it.

[qodo-free-for-open-source-projects]

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

[davidfirst]

Status: green except e2e_test and bit_pr — both blocked on env-side TS6 gaps, not on this PR's own code

What this PR does

Bumps the workspace to TypeScript 6.0.3 (+ root tsconfig.json: ignoreDeprecations: "6.0", types: ["node", "jest"], and empty-module ambient stubs for the side-effect-only imports reset-css / @mdx-js/loader).

Bumping the workspace typescript means the from-source bit binary now compiles components under TS6, which surfaces a chain of TS6-compat issues. The first is fixed here; the rest live in the envs.

---

❌ e2e_test — 20 of 40 containers

Two TS6 errors, in order of appearance:

1. TS5107 — the shipped compile-tsconfig templates used moduleResolution: "node" (node10), which TS6 rejects as a hard error.
   ✅ Fixed in this PR — switched the templates (scopes/harmony/aspect/typescript/tsconfig.json, scopes/typescript/typescript/tsconfig.default.json, scopes/react/react/typescript/*) to moduleResolution: "bundler". This cleared ~half the containers (40 → 20).

2. TS2882 — import 'reset-css' (a side-effect-only, typeless CSS import) in scope.tsx and workspace.tsx has no resolvable module declaration under TS6, so core-aspect-env fails to compile them (Cannot find module or type declarations for side-effect import of 'reset-css').
   ⏳ Not yet fixed. A root-level ambient stub does not reach the env/capsule compile (single-program/from-source build doesn't pull in a sibling .d.ts). The declaration must live in core-aspect-env itself — add declare module 'reset-css' {} to its types/style.d.ts, alongside the existing *.css / *.svg stubs.

❌ bit_pr — 1 of 54 tasks

GeneratePreview for teambit.ui-foundation/ui/side-bar fails with dist/index.js: Unexpected token 'export'. Under TS6, v17/react-env compiles side-bar to an ESM dist/index.js that its own preview webpack/babel-loader then can't parse.

• This is not a v17/react-env@1.2.7 regression — a contemporary, unrelated PR built the same day compiled side-bar's preview cleanly with the identical 1.2.7.
• The trigger is the TS6 bump flowing into the env's compilation: envs resolve the hoisted workspace typescript, so bumping it to 6.0.3 changes side-bar's emitted module format.
• Fix belongs in v17/react-env — TS6-adapt it so its preview build emits/consumes a consistent module format.

⚠️ The bump is also incomplete for the bit binary itself

pnpm-lock.yaml still resolves teambit.harmony/bit → typescript@5.9.2. That dep lives in the component model (set via a past bit deps set), so workspace.jsonc can't move it — see the note already in the scopes/harmony/bit variant. Until this is fixed, the shipped bvm binary would still bundle TS5, even though the from-source CI build uses TS6.

---

Suggested path forward

This PR is effectively gated on the env-side TS6 migration. The bit2-local changes here (bundler tsconfigs + ambient stubs) are complete and correct. To turn CI green, three things outside this PR are needed:

1. bit deps set teambit.harmony/bit typescript@6.0.3 + bit install — so the shipped binary actually uses TS6.
2. core-aspect-env: declare reset-css (and any other bare side-effect CSS imports) in its types/*.d.ts, then release → clears the e2e TS2882 containers.
3. v17/react-env: TS6-adapt its preview build, then release → clears the side-bar task.

Recommendation: hold this PR until (2) and (3) are released, then re-run CI. Nothing further is fixable inside bit2 until then.