chore(node): update Node.js version to 24.18.1 by GiladShoham · Pull Request #10555 · teambit/bit

GiladShoham · 2026-08-02T14:00:00Z

Update Node.js version to 24.18.1 (latest Node 24 LTS) across the project. This ensures compatibility with the latest features and security patches.

Replaces #9933 (branch renamed from chore/update-nodejs-24-6-0 to chore/update-nodejs-24 and version bumped from 24.13.0 to 24.18.1).

qodo-free-for-open-source-projects · 2026-08-02T14:00:46Z

PR Summary by Qodo

Update project Node.js baseline to 24.18.1 across CI, Docker, and workspace config

⚙️ Configuration changes 📝 Documentation 🕐 20-40 Minutes

AI Description

• Bump CI and Docker base images to Node.js 24.18.1 (Node 24 LTS).
• Align workspace engine/tooling constraints to require Node 24.18.1.
• Fix/ignore MDX formatting cases where Prettier escapes JSX comments incorrectly.

Diagram

graph TD
  Dev["Developer"] --> Repo["Repo configs"] --> CI["CircleCI"] --> DockerBuild["Docker build jobs"] --> Registry[("Published images")]
  Repo --> Local["workspace.jsonc (engines)"]
  Repo --> Docs["MDX docs"]

High-Level Assessment

The following are alternative approaches to this PR:

1. Centralize Node version in a single source-of-truth file

➕ Reduces drift between CircleCI, Dockerfiles, and workspace tooling
➕ Simplifies future version bumps (one change propagates everywhere)
➖ Requires adding a small templating/sync step (CI or repo script)
➖ May add process overhead if contributors expect direct edits in each file

2. Run a CI matrix for Node 22 + Node 24 during transition

➕ Detects regressions earlier if some consumers still use Node 22
➕ Provides safer rollout for ecosystem dependencies
➖ Increases CI time/cost
➖ Adds complexity to workflows and artifact naming

Recommendation: The PR’s approach (directly bumping Node versions in each integration point) is appropriate for a clean cutover to Node 24 LTS. If version bumps are frequent or drift has been a recurring issue, consider adding a single source-of-truth + sync step later; otherwise keep this straightforward change. A dual-version CI matrix is only worth it if you must maintain Node 22 compatibility for downstream users.

Files changed (8) +53 / -53

Documentation (2) +17 / -20

react.mdxNormalize code examples to avoid MDX/Prettier escaping issues +15/-19

Normalize code examples to avoid MDX/Prettier escaping issues
• Reformats TS/TSX code examples (semicolons, trailing commas, inline props typing) to align with formatting expectations and reduce tooling friction. No runtime behavior is changed (documentation-only).
scopes/react/aspect-docs/react/react.mdx

loader-fallback.docs.mdxFix MDX fenced code block to avoid comment/formatter conflicts +2/-1

Fix MDX fenced code block to avoid comment/formatter conflicts
• Adjusts the live code fence delimiter (uses four backticks) and adds a matching closing fence. This prevents MDX/Prettier from mis-parsing the example inside JSX comments.
scopes/react/ui/loader-fallback/loader-fallback.docs.mdx

Other (6) +36 / -33

config.ymlSwitch CircleCI executors and Docker build jobs to Node 24.18.1 +27/-27

Switch CircleCI executors and Docker build jobs to Node 24.18.1

• Updates the default CircleCI Node image and Windows nvm installs to 24.18.1. Renames Docker jobs from node_22 to node_24 and updates Docker build args/tag suffixes (including alpine and server image flows) to publish Node 24.18.1-tagged images.

.circleci/config.yml

.prettierignoreIgnore MDX files that break under Prettier JSX comment escaping +4/-1

Ignore MDX files that break under Prettier JSX comment escaping
• Adds specific MDX documentation files to .prettierignore due to JSX comment escaping issues. Also fixes newline/formatting around an existing ignored path.
.prettierignore

Dockerfile-bitBump Docker base ARG to node:24.18.1 +1/-1

Bump Docker base ARG to node:24.18.1
• Updates the BASE_IMAGE build argument to pull Node 24.18.1 as the default base image for the Bit CLI container build.
scripts/docker-teambit-bit/Dockerfile-bit

Dockerfile-bit-alpineBump Alpine Docker base ARG to node:24.18.1-alpine +1/-1

Bump Alpine Docker base ARG to node:24.18.1-alpine
• Updates the BASE_IMAGE build argument to Node 24.18.1 Alpine for the alpine variant container build.
scripts/docker-teambit-bit/Dockerfile-bit-alpine

Dockerfile-bit-non-rootBump non-root Docker base ARG to node:24.18.1 +1/-1

Bump non-root Docker base ARG to node:24.18.1
• Updates the BASE_IMAGE build argument to Node 24.18.1 for the non-root Bit CLI image variant.
scripts/docker-teambit-bit/Dockerfile-bit-non-root

workspace.jsoncAlign workspace Node version and bvm node setting to 24.18.1 +2/-2

Align workspace Node version and bvm node setting to 24.18.1

• Updates the workspace-level nodeVersion to 24.18.1 and aligns the bvm.node field accordingly. This enforces Node 24.18.1 as the supported baseline for local development/tooling.

workspace.jsonc

qodo-free-for-open-source-projects · 2026-08-02T14:02:19Z

Code Review by Qodo

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

1. Dangling CircleCI job refs 🐞 Bug ☼ Reliability

Description

CircleCI workflow harmony_deploy_manual still invokes
docker_build_node_22/docker_non_root_build_node_22/server_docker_build_node_22, but this PR
renames those jobs to *_node_24, leaving the manual deploy workflow referencing undefined jobs and
failing configuration validation/execution.

Code

.circleci/config.yml[1203]
+  docker_build_node_24:

Evidence

The PR adds/defines the Node 24 docker jobs, but the manual deploy workflow at the bottom of the
file still references the old Node 22 job names. Since the old job definitions were renamed (not
kept as aliases), those workflow steps point to undefined jobs.

.circleci/config.yml[1202-1247]
.circleci/config.yml[1636-1676]

Agent prompt

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

## Issue description
CircleCI jobs were renamed from `*_node_22` to `*_node_24`, but the `harmony_deploy_manual` workflow still references the old job names, which no longer exist.
## Issue Context
The renamed job definitions exist as `docker_build_node_24`, `docker_non_root_build_node_24`, and `server_docker_build_node_24`.
## Fix Focus Areas
- .circleci/config.yml[1636-1676]
- .circleci/config.yml[1202-1248]
## Implementation notes
- In `harmony_deploy_manual`, replace:
- `docker_build_node_22` -> `docker_build_node_24`
- `docker_non_root_build_node_22` -> `docker_non_root_build_node_24`
- `server_docker_build_node_22` -> `server_docker_build_node_24`
- Update `requires:` references accordingly (e.g., `server_docker_build_node_24` should require `docker_build_node_24`).
- Run CircleCI config validation after the change.

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

2. Node engines not aligned 🐞 Bug ☼ Reliability ⭐ New

Description

The PR standardizes the project toolchain on Node 24.18.1 (CI images and workspace nodeVersion), but
the root package.json still declares engines.node as ">=22.13.0", so tools/users may continue
running Node 22 despite the project moving to Node 24. This leaves the supported Node version
ambiguous and increases the chance of local/CI environment drift.

Code

workspace.jsonc[R732-733]

+    "nodeVersion": "24.18.1",
    "engineStrict": true,

Evidence
The PR explicitly pins Node 24.18.1 in the workspace configuration, while the repository’s root
package metadata still allows Node 22. This mismatch is visible in the checked-in configs and can
cause developers/tools to pick a Node version that no longer matches the project’s standardized
CI/tooling runtime.
workspace.jsonc[729-734]
package.json[1-8]
scopes/dependencies/dependency-resolver/dependency-resolver.main.runtime.ts[712-742]
scopes/dependencies/dependency-resolver/dependency-installer.ts[356-396]

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 repo is now configured to build/test with Node 24.18.1, but `package.json` still advertises Node 22 compatibility (`engines.node: ">=22.13.0"`). This makes it easy for developers/automation to keep using Node 22 even though CI/workspace tooling is pinned to Node 24.

## Issue Context
- CI and workspace config are updated to Node `24.18.1`.
- Bit’s dependency installer passes `nodeVersion`/`engineStrict` from workspace config down into package-manager install options; however, the repository’s public/standard compatibility contract for developers is typically the root `package.json` `engines` field.

## Fix Focus Areas
- package.json[1-8]
- workspace.jsonc[729-734]

### Suggested change
Update `package.json -> engines.node` to reflect the intended supported runtime (e.g. `>=24.18.1` or `^24.18.0`), so local environments are forced to match the Node version this PR standardizes on.

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

3. ~~Unmatched MDX fence~~ ✓ Resolved 🐞 Bug ≡ Correctness

Description

loader-fallback.docs.mdx adds a standalone four-backtick fence (````) after the JSX comment, which
is not paired with an opening fence outside the comment and can cause the doc to be parsed/rendered
incorrectly (e.g., starting an unterminated code block).

Code

scopes/react/ui/loader-fallback/loader-fallback.docs.mdx[46]
+````

Evidence

The file now ends with a  ``  line outside the JSX comment, while the earlier  ``tsx live 
appears inside the JSX comment. This leaves an unmatched markdown fence at the document level.

scopes/react/ui/loader-fallback/loader-fallback.docs.mdx[24-46]

Agent prompt

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

## Issue description
A trailing ` ```` ` line was added outside the JSX comment block, creating an unmatched fenced-code delimiter in the MDX document.
## Issue Context
The opening ` ````tsx live ` is inside a JSX comment (`{/* ... */}`), so it does not act as a real markdown fence at the document level. The newly added trailing ` ```` ` is outside the comment and *does* act as markdown.
## Fix Focus Areas
- scopes/react/ui/loader-fallback/loader-fallback.docs.mdx[24-46]
## Implementation notes
Choose one:
1) Keep the example commented out:
- Remove the trailing standalone ` ```` ` line (and optionally revert the inner opener back to ``` for consistency inside the comment).
2) Show the example as a real fenced block:
- Remove the `{/* ... */}` wrappers and use a normal fenced block with matching open/close (either ```...``` or ````...```` consistently).

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

_{To customize comments, go to the Qodo configuration screen, or learn more in the docs.}

Previous review results

Review updated until commit 6ec1d09 ⚖️ Balanced

Results up to commit aaaf52a

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

1. Dangling CircleCI job refs 🐞 Bug ☼ Reliability

Description

CircleCI workflow harmony_deploy_manual still invokes
docker_build_node_22/docker_non_root_build_node_22/server_docker_build_node_22, but this PR
renames those jobs to *_node_24, leaving the manual deploy workflow referencing undefined jobs and
failing configuration validation/execution.

Code

.circleci/config.yml[1203]
+  docker_build_node_24:

Evidence

The PR adds/defines the Node 24 docker jobs, but the manual deploy workflow at the bottom of the
file still references the old Node 22 job names. Since the old job definitions were renamed (not
kept as aliases), those workflow steps point to undefined jobs.

.circleci/config.yml[1202-1247]
.circleci/config.yml[1636-1676]

Agent prompt

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

## Issue description
CircleCI jobs were renamed from `*_node_22` to `*_node_24`, but the `harmony_deploy_manual` workflow still references the old job names, which no longer exist.
## Issue Context
The renamed job definitions exist as `docker_build_node_24`, `docker_non_root_build_node_24`, and `server_docker_build_node_24`.
## Fix Focus Areas
- .circleci/config.yml[1636-1676]
- .circleci/config.yml[1202-1248]
## Implementation notes
- In `harmony_deploy_manual`, replace:
- `docker_build_node_22` -> `docker_build_node_24`
- `docker_non_root_build_node_22` -> `docker_non_root_build_node_24`
- `server_docker_build_node_22` -> `server_docker_build_node_24`
- Update `requires:` references accordingly (e.g., `server_docker_build_node_24` should require `docker_build_node_24`).
- Run CircleCI config validation after the change.

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

2. ~~Unmatched MDX fence~~ ✓ Resolved 🐞 Bug ≡ Correctness

Description

loader-fallback.docs.mdx adds a standalone four-backtick fence (````) after the JSX comment, which
is not paired with an opening fence outside the comment and can cause the doc to be parsed/rendered
incorrectly (e.g., starting an unterminated code block).

Code

scopes/react/ui/loader-fallback/loader-fallback.docs.mdx[46]
+````

Evidence

The file now ends with a  ``  line outside the JSX comment, while the earlier  ``tsx live 
appears inside the JSX comment. This leaves an unmatched markdown fence at the document level.

scopes/react/ui/loader-fallback/loader-fallback.docs.mdx[24-46]

Agent prompt

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

## Issue description
A trailing ` ```` ` line was added outside the JSX comment block, creating an unmatched fenced-code delimiter in the MDX document.
## Issue Context
The opening ` ````tsx live ` is inside a JSX comment (`{/* ... */}`), so it does not act as a real markdown fence at the document level. The newly added trailing ` ```` ` is outside the comment and *does* act as markdown.
## Fix Focus Areas
- scopes/react/ui/loader-fallback/loader-fallback.docs.mdx[24-46]
## Implementation notes
Choose one:
1) Keep the example commented out:
- Remove the trailing standalone ` ```` ` line (and optionally revert the inner opener back to ``` for consistency inside the comment).
2) Show the example as a real fenced block:
- Remove the `{/* ... */}` wrappers and use a normal fenced block with matching open/close (either ```...``` or ````...```` consistently).

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

Results up to commit 1a07c39

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

1. Dangling CircleCI job refs 🐞 Bug ☼ Reliability

Description

CircleCI workflow harmony_deploy_manual still invokes
docker_build_node_22/docker_non_root_build_node_22/server_docker_build_node_22, but this PR
renames those jobs to *_node_24, leaving the manual deploy workflow referencing undefined jobs and
failing configuration validation/execution.

Code

.circleci/config.yml[1203]
+  docker_build_node_24:

Evidence

The PR adds/defines the Node 24 docker jobs, but the manual deploy workflow at the bottom of the
file still references the old Node 22 job names. Since the old job definitions were renamed (not
kept as aliases), those workflow steps point to undefined jobs.

.circleci/config.yml[1202-1247]
.circleci/config.yml[1636-1676]

Agent prompt

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

## Issue description
CircleCI jobs were renamed from `*_node_22` to `*_node_24`, but the `harmony_deploy_manual` workflow still references the old job names, which no longer exist.

## Issue Context
The renamed job definitions exist as `docker_build_node_24`, `docker_non_root_build_node_24`, and `server_docker_build_node_24`.

## Fix Focus Areas
- .circleci/config.yml[1636-1676]
- .circleci/config.yml[1202-1248]

## Implementation notes
- In `harmony_deploy_manual`, replace:
 - `docker_build_node_22` -> `docker_build_node_24`
 - `docker_non_root_build_node_22` -> `docker_non_root_build_node_24`
 - `server_docker_build_node_22` -> `server_docker_build_node_24`
- Update `requires:` references accordingly (e.g., `server_docker_build_node_24` should require `docker_build_node_24`).
- Run CircleCI config validation after the change.

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

2. Unmatched MDX fence 🐞 Bug ≡ Correctness

Description

loader-fallback.docs.mdx adds a standalone four-backtick fence (````) after the JSX comment, which
is not paired with an opening fence outside the comment and can cause the doc to be parsed/rendered
incorrectly (e.g., starting an unterminated code block).

Code

scopes/react/ui/loader-fallback/loader-fallback.docs.mdx[46]
+````

Evidence

The file now ends with a  ``  line outside the JSX comment, while the earlier  ``tsx live 
appears inside the JSX comment. This leaves an unmatched markdown fence at the document level.

scopes/react/ui/loader-fallback/loader-fallback.docs.mdx[24-46]

Agent prompt

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

## Issue description
A trailing ` ```` ` line was added outside the JSX comment block, creating an unmatched fenced-code delimiter in the MDX document.

## Issue Context
The opening ` ````tsx live ` is inside a JSX comment (`{/* ... */}`), so it does not act as a real markdown fence at the document level. The newly added trailing ` ```` ` is outside the comment and *does* act as markdown.

## Fix Focus Areas
- scopes/react/ui/loader-fallback/loader-fallback.docs.mdx[24-46]

## Implementation notes
Choose one:
1) Keep the example commented out:
- Remove the trailing standalone ` ```` ` line (and optionally revert the inner opener back to ``` for consistency inside the comment).

2) Show the example as a real fenced block:
- Remove the `{/* ... */}` wrappers and use a normal fenced block with matching open/close (either ```...``` or ````...```` consistently).

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

qodo-free-for-open-source-projects · 2026-08-02T14:02:20Z


  # ========== Docker Jobs ==========
-  docker_build_node_22:
+  docker_build_node_24:


1. Dangling circleci job refs 🐞 Bug ☼ Reliability

CircleCI workflow harmony_deploy_manual still invokes docker_build_node_22/docker_non_root_build_node_22/server_docker_build_node_22, but this PR renames those jobs to *_node_24, leaving the manual deploy workflow referencing undefined jobs and failing configuration validation/execution.

Agent Prompt

## Issue description CircleCI jobs were renamed from `*_node_22` to `*_node_24`, but the `harmony_deploy_manual` workflow still references the old job names, which no longer exist. ## Issue Context The renamed job definitions exist as `docker_build_node_24`, `docker_non_root_build_node_24`, and `server_docker_build_node_24`. ## Fix Focus Areas - .circleci/config.yml[1636-1676] - .circleci/config.yml[1202-1248] ## Implementation notes - In `harmony_deploy_manual`, replace: - `docker_build_node_22` -> `docker_build_node_24` - `docker_non_root_build_node_22` -> `docker_non_root_build_node_24` - `server_docker_build_node_22` -> `server_docker_build_node_24` - Update `requires:` references accordingly (e.g., `server_docker_build_node_24` should require `docker_build_node_24`). - Run CircleCI config validation after the change.

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

…ed to Node bump

qodo-free-for-open-source-projects · 2026-08-02T14:10:21Z

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

Prettier incorrectly escapes JSX comment markers (\`/* */\` → \`\/* *\/\`) inside these two MDX files' code blocks, breaking the comment syntax. Excludes both files from prettier and fixes the existing bad escaping. Split out of the Node 24 branch (#10555), where it was an unrelated change picked up along the way.

qodo-free-for-open-source-projects · 2026-08-09T10:34:17Z

+    "nodeVersion": "24.18.1",
    "engineStrict": true,


1. Node engines not aligned 🐞 Bug ☼ Reliability

The PR standardizes the project toolchain on Node 24.18.1 (CI images and workspace nodeVersion), but the root package.json still declares engines.node as ">=22.13.0", so tools/users may continue running Node 22 despite the project moving to Node 24. This leaves the supported Node version ambiguous and increases the chance of local/CI environment drift.

Agent Prompt

## Issue description The repo is now configured to build/test with Node 24.18.1, but `package.json` still advertises Node 22 compatibility (`engines.node: ">=22.13.0"`). This makes it easy for developers/automation to keep using Node 22 even though CI/workspace tooling is pinned to Node 24. ## Issue Context - CI and workspace config are updated to Node `24.18.1`. - Bit’s dependency installer passes `nodeVersion`/`engineStrict` from workspace config down into package-manager install options; however, the repository’s public/standard compatibility contract for developers is typically the root `package.json` `engines` field. ## Fix Focus Areas - package.json[1-8] - workspace.jsonc[729-734] ### Suggested change Update `package.json -> engines.node` to reflect the intended supported runtime (e.g. `>=24.18.1` or `^24.18.0`), so local environments are forced to match the Node version this PR standardizes on.

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

qodo-free-for-open-source-projects · 2026-08-09T10:34:18Z

Code review by qodo was updated up to the latest commit 6ec1d09

GiladShoham and others added 9 commits August 17, 2025 10:59

chore(node): update Node.js version to 24.6.0

3234caa

fix: update recommended and supported Node.js versions to <25.0.0

9204361

Merge branch 'master' into chore/update-nodejs-24-6-0

b1d719d

Merge master and update Node.js to 24.13.0

87082b6

fix: correct MDX comment syntax and exclude from prettier

04a2f61

Merge branch 'master' into chore/update-nodejs-24-6-0

98a8da0

Merge branch 'master' into chore/update-nodejs-24-6-0

24261fd

Merge branch 'master' into chore/update-nodejs-24-6-0

7c4a283

chore(node): bump Node.js to 24.18.1

1a07c39

GiladShoham mentioned this pull request Aug 2, 2026

chore(node): update Node.js version to 24.13.0 #9933

Closed

qodo-free-for-open-source-projects Bot reviewed Aug 2, 2026

View reviewed changes

revert: drop unrelated MDX/prettierignore changes to keep branch scop…

aaaf52a

…ed to Node bump

GiladShoham mentioned this pull request Aug 2, 2026

fix: exclude MDX files with JSX comments from prettier #10556

Merged

guysaar223 approved these changes Aug 2, 2026

View reviewed changes

zkochan approved these changes Aug 2, 2026

View reviewed changes

Merge branch 'master' into chore/update-nodejs-24

6ec1d09

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

View reviewed changes

Navigation Menu

Uh oh!

chore(node): update Node.js version to 24.18.1 - #10555

chore(node): update Node.js version to 24.18.1#10555
GiladShoham wants to merge 11 commits into
masterfrom
chore/update-nodejs-24

GiladShoham commented Aug 2, 2026

Uh oh!

qodo-free-for-open-source-projects Bot commented Aug 2, 2026

Uh oh!

qodo-free-for-open-source-projects Bot commented Aug 2, 2026 •

edited

Loading

Uh oh!

qodo-free-for-open-source-projects Bot Aug 2, 2026

Uh oh!

Uh oh!

qodo-free-for-open-source-projects Bot commented Aug 2, 2026

Uh oh!

qodo-free-for-open-source-projects Bot Aug 9, 2026

Uh oh!

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

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Uh oh!

Conversation

GiladShoham commented Aug 2, 2026

Uh oh!

qodo-free-for-open-source-projects Bot commented Aug 2, 2026

PR Summary by Qodo

Uh oh!

qodo-free-for-open-source-projects Bot commented Aug 2, 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 Aug 2, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

qodo-free-for-open-source-projects Bot commented Aug 2, 2026

Uh oh!

qodo-free-for-open-source-projects Bot Aug 9, 2026

Choose a reason for hiding this comment

Uh oh!

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

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

qodo-free-for-open-source-projects Bot commented Aug 2, 2026 •

edited

Loading