English 한국어

The private root workspace and 35 Node-bound public packages, including @fluojs/platform-nextjs, declare engines.node: ">=24.0.0 <27". Adopting Node 24 LTS is a lifecycle and support-policy decision, not a claim that a dependency or a new runtime API requires Node 24. Node 20 and Node 22 are not supported by the upcoming major release.

The node-support matrix in .github/workflows/ci.yml calls .github/workflows/node-verification.yml and is required by the aggregate verify gate. A deterministic latest-24 preflight runs frozen install, build, typecheck, lint, platform governance, and the full tooling project before the runtime fan-out. Every Node version then verifies the same full build, typecheck, lint, and test coverage as local pnpm verify. In CI, pnpm build is followed by independent jobs for pnpm typecheck and pnpm lint, sharded tests, and generated starter verification. Package tests use four shards and tooling tests use two shards. The apps and examples projects each run in full once in the first tooling shard job; each test process retains --maxWorkers=1. A small change scope does not skip this full Node verification.

pnpm verify:local records an exact-head local receipt: worktree root, head and tree identities, merge-base and diff identity, command plan, logs, environment, and limits. A receipt is invalid when its head, tree, or diff changes, and --plan never emits a passing receipt. The local command intentionally cannot prove CI-only runners, GitHub artifact transfer, or aggregate job semantics. Those dimensions remain CI evidence; failure census reports preserve attempts and completed failed jobs instead of treating a later rerun as proof that no failure occurred.

Receipt identity also binds a clean Git status digest at startup, each command boundary, and finalization. Artifact consumers use exact run/name/SHA/digest provenance and bounded retries only for observed intermediary 403 and narrow transient 5xx responses; authentication, ordinary authorization, malformed metadata, expired artifacts, and digest mismatch fail immediately. The census queries attempt details and attempt-specific jobs, applies a strict UTC [since, until) window, and records pagination/completeness limits rather than silently treating unavailable data as success.

Build artifacts are transferred only within the same workflow run, commit, and Node version. A tar archive preserves package dist directories and the CLI's generated dependency metadata, including executable permissions and symbolic links; it does not bypass public declaration fixtures or package global setup. Generated starter verification runs after the build without waiting for tests to finish. Latest 24.x consolidates the former duplicate PR verification and runs pnpm verify:docs once. The aggregate gate does not treat a required job's failure, cancellation, or skip as success.

Outside Node verification, the web runtime adapter portability suite exercises all Bun, Deno, and Cloudflare Workers cases in one job to avoid repeated project setup. Native response cookie verification also builds the HTTP helper once in one job, then runs the three runtime commands sequentially. A failure in any command still blocks the required Verify gate; Bun native routing/lifecycle and Deno platform verification remain separate jobs.

The focused test:node-floor command remains available for local checks, not as a substitute for full CI verification. It covers manifest classification, all scaffold profiles, config env-file/watch behavior, the published portable runtime import, Node HTTP listeners, adapter portability, and the existing Vite compatibility seam. CI does not substitute a later 24.x patch for the exact 24.0.0 claim.

These eight public roots intentionally omit engines.node: @fluojs/config, @fluojs/email, @fluojs/i18n, @fluojs/platform-bun, @fluojs/platform-cloudflare-workers, @fluojs/platform-deno, @fluojs/react, and @fluojs/runtime. Do not restore engines merely to match neighboring manifests.

Package-wide Node metadata is not a claim about every conditional export or runtime-native adapter. Existing Bun, Deno, and Workers behavior remains governed by each package's README. Config's in-memory root stays portable; env-file/default .env loading and watch mode are Node-only features supported on >=24.0.0 <27. Their existing capability guard still raises CONFIG_RUNTIME_UNAVAILABLE when the host cannot supply the builtin boundary. There is no new Node version check at import or feature invocation.

Generated Node HTTP (Fastify, Express, raw Node), mixed, all seven microservice transports, and React SSR + Fastify starters declare the same engine range, build for node24, and use @types/node@^24.0.0. Bun and Deno engines and native build/start commands remain unchanged. Workers' existing Node engine describes local CLI/Wrangler tooling, not the deployed isolate.

1. Before upgrading affected packages, replace Node 20/22 local installations, CI runners, and deployment hosts with latest Node 24 LTS. Use >=24.0.0 <27 for the application's engines.node; do not use --ignore-engines as a migration.
2. Replace container base images such as node:20-slim with node:24-slim in both build and runtime stages. Rebuild the image and reinstall dependencies, including native addons, under the new runtime.
3. Existing generated Node projects are not rewritten by upgrading the CLI. Update their Vite server build target from node20 to node24 and their Node typings to @types/node@^24.0.0; refresh the lockfile with the project's selected package manager.
4. Run the application's install, build, typecheck, and tests on Node 24. Check its HTTP listener and microservice startup/shutdown, or the first React page and hydration when applicable. Keep exact 24.0.0 and latest 26.x checks if the application advertises this complete range.
5. For non-Node deployments, retain native engine metadata and deployment commands. Upgrade only Node-hosted developer tooling. Pass explicit in-memory config maps on portable hosts instead of assuming Node env-file/watch support.

For the complete upcoming coordinated-release order (Node, packages, imports, then config/toolchain), follow the consumer migration guide. Every stable public package has explicit major intent, including config's Node-only feature support; React remains a 0.x minor. Only Changesets generates package versions and changelogs, and the maintainer owns actual release and document publication. #3169 remains the umbrella until the user-run release.