fix: declare one supported Node.js range, ^22.18.0 || ^24.11.0 || >=26.0.0

[wmadden-electric]

Linked issue

n/a — small change

Summary

Composer's published packages now declare the same supported Node.js range as every other Prisma 8 tool:

// @prisma/composer, @prisma/composer-cli, @prisma/composer-prisma-cloud — before
"engines": { "node": ">=22.18.0" }

// after, and what create-prisma and the projects it generates already declare
"engines": { "node": "^22.18.0 || ^24.11.0 || >=26.0.0" }

In prose: Node.js 22.18 or newer on the 22 line, 24.11 or newer on the 24 line, or 26 or newer, each with the npm that Node release ships (npm 10 on Node 22).

Why one range

A user starts a Prisma 8 project with create-prisma, which writes the range above into their package.json. Composer then said something different: >=22.18.0. Two tools in the same project gave two answers to "which Node do I need?", and the README, guides and skill repeated Composer's answer. Prisma decided that every Prisma 8 tool supports exactly one range, so this PR makes Composer match.

Why these three bounds

• 22.18.0 stays the floor. It is the first release that strips TypeScript types by default, and Composer loads the app's .ts entry with Node's own loader. On 22.17 prisma deploy stops at ERR_UNKNOWN_FILE_EXTENSION.
• 24.11.0 is Node 24's first long-term-support release. Releases before it on the 24 line are no longer in the range.
• 26.0.0 opens the 26 line and everything after it.

What changes for users

• On a Node.js release inside the range: nothing.
• On a Node version outside the range, such as 24.0 to 24.10, what happens on install depends on the package manager. npm and pnpm print an engines warning (pnpm fails with engine-strict). Yarn 1 refuses to install unless run with --ignore-engines, so a Yarn 1 user there can no longer install Composer. Bun and Yarn 2 or newer ignore engines. Composer itself behaves as before; it has no runtime version check.
• When prisma runs under Bun and finds no node on PATH, the DEPLOY.NODE_MISSING fix message now names the range.

Changes

• engines.node set to the range in all 14 manifests that declared one: the three published packages and the 11 private @internal/* packages.
• scripts/supported-node-range.test.mjs, a new test: every published package declares the range, and no workspace manifest declares a different one.
• DEPLOY.NODE_MISSING fix message (packages/0-framework/3-tooling/cli/src/run-alchemy.ts) uses the prose wording, with a test.
• README, docs/guides/getting-started.md, docs/guides/deploying.md, docs/design/10-domains/deploy-cli.md and skills/prisma-composer-core-concepts/SKILL.md use the prose wording. The skill gains a failure-mode entry: ERR_UNKNOWN_FILE_EXTENSION on the app's own .ts entry means Node is too old.
• CI: the node-floor job is now a matrix over 22.18.0, 24.11.0 and 26.0.0. The 22.18 entry keeps the check name "Node 22.18 floor". No required check or job dependency refers to that name.
• scripts/check-cli-engine-pin-host.test.mjs removes a symlink with unlinkSync instead of rmSync. On Node 24.11 to 24.13, rmSync on a symlink to a directory throws EISDIR, which would have failed the new 24.11 job.

Testing performed

• pnpm typecheck, pnpm lint, pnpm lint:deps: pass.
• bun test in packages/0-framework/3-tooling/cli: pass. The new DEPLOY.NODE_MISSING test failed before the message change.
• node --test scripts/*.test.mjs scripts/*.test.ts on Node 24.11.1, 24.16.0 and 26.8.1: pass. The new range test failed before the manifest change.
• node scripts/check-floor-imports.mjs on Node 24.11.1 and 26.8.1: all 17 published entrypoints load.
• Locally I used the nearest installed versions (24.11.1, 26.8.1). CI runs the exact floors: 22.18.0, 24.11.0 and 26.0.0.
• pnpm test in website (renders the guides and checks links): pass.

Checklist

• All commits are signed off (git commit -s) per the DCO. The DCO status check will block merge if any commit is missing a Signed-off-by: trailer.
• I read CONTRIBUTING.md and the change is scoped to one logical concern.
• The PR title is a conventional commit (feat, fix, chore, docs, refactor, test, build) — PR titles drive the auto-generated release notes.
• Tests are updated (or n/a if the change is doc-only / refactor with no behavioural delta).

Notes for the reviewer

Left alone on purpose: .tool-versions (node 24.16.0, the build toolchain, inside the range); pnpm-lock.yaml entries, which record third-party packages' own engines; the copies of other projects' docs under docs/design/04-inspirations/; and the npm 10 comments in scripts/check-npm-effect-resolution.mjs and skills-contrib/upgrade-alchemy-effect/SKILL.md, which already match the decision.

Alternatives considered:

• Keep >=22.18.0. It is the technical floor for type stripping, but it disagrees with create-prisma and admits releases Prisma does not support.
• A runtime version check in the CLI. It would duplicate what package managers already do with engines, and Composer has none today. Not added.
• Test only 22.18.0 in CI. It leaves the 24.11 and 26.0 lower bounds unchecked. The matrix costs two extra jobs.

Agent: maui-32

[prisma-gizmo]

✅ Gizmo reviewed 9107e72 — posted 0 inline comment(s) this pass.

Open findings: none

Change walkthrough

This PR replaces Composer's open-ended engines.node: ">=22.18.0" with the single supported range ^22.18.0 || ^24.11.0 || >=26.0.0 across all 14 workspace manifests, so Composer answers "which Node do I need?" identically to the rest of Prisma 8 (including what create-prisma writes into user projects). Every user-facing surface that stated a requirement was reworded to the matching prose.

Manifests — All three published packages (packages/9-public/composer and siblings) and the 11 private @internal/* packages now declare the same range. No other manifest in the repo declares a conflicting engines.node, and the range semantics match the prose (22-line from 22.18, 24-line from 24.11, 26 and later; odd pre-LTS lines 23/25 excluded).

Guardrail test — New scripts/supported-node-range.test.mjs asserts every packages/9-public manifest declares the exact range and that no workspace manifest under packages/examples/test/website declares a different engines.node. It runs automatically under pnpm test:scripts (glob pickup).

CI — The node-floor job in ci.yml becomes a fail-fast: false matrix over the three line floors (22.18.0, 24.11.0, 26.0.0), with the floor version threaded via FLOOR_NODE into the mise install, the exact-version assertion, and the check name (the 22.18 entry still reports as "Node 22.18 floor"; no other workflow or required-check reference names it). The build still runs on the .tool-versions toolchain before Node drops to the floor.

CLI error message — run-alchemy.ts names the full range in the DEPLOY.NODE_MISSING fix, with a test asserting the exact wording. Composer gains no runtime version check, consistent with the stated alternative.

Test infrastructure fix — check-cli-engine-pin-host.test.mjs switches to unlinkSync for removing the node_modules/@prisma/composer-cli symlink (a link to a directory), avoiding rmSync's EISDIR behavior on Node 24.11–24.13 so the new 24.11 CI entry can pass; rmSync remains used for temp-dir cleanup.

Docs and skill — README, both guides, the deploy-cli domain doc, and the skill's new failure-mode entry 11 all carry the same prose wording and the literal range; no stale >=22.18.0 references remain outside the intentionally-untouched files (.tool-versions, docs/design/04-inspirations copies, npm-10 comments).

[coderabbitai]

Important

• 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

• Configuration used: Organization UI
• Review profile: ASSERTIVE
• Plan: Advanced
• Run ID: 3abbe366-6e94-4224-bcf0-205350e3e902

---

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

---

_{Comment @coderabbitai help to get the list of available commands.}

[pkg-pr-new]

Open in StackBlitz

npm i https://pkg.pr.new/@prisma/composer@351

npm i https://pkg.pr.new/@prisma/composer-cli@351

npm i https://pkg.pr.new/@prisma/composer-prisma-cloud@351

commit: 9107e72

[prisma-gizmo]

New findings: none · trace

[prisma-gizmo]

No critical or major Gizmo finding is open and the head commit has been reviewed. Approving.