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

[GiladShoham]

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]

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

Loading

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]

Code Review by Qodo

🐞 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

---

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

Previous review results

Review updated until commit aaaf52a ⚖️ Balanced

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]

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

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

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