fix(hosting): use nodejs24.x for SSR framework compute and fail loudly on unknown runtimes (#361) - #374
Open
sarayev wants to merge 4 commits into
Open
fix(hosting): use nodejs24.x for SSR framework compute and fail loudly on unknown runtimes (#361)#374sarayev wants to merge 4 commits into
sarayev wants to merge 4 commits into
Conversation
… workflow The PR head branch name was interpolated directly into a run: shell body, allowing someone who opens a PR from a branch named release/swift-<payload> to execute arbitrary shell commands on the runner, which has a contents:write GITHUB_TOKEN available. - Pass github.event.pull_request.head.ref via env: instead of inlining it - Pass steps.version.outputs.version via env: (second-order taint) - Add a SemVer allowlist + explicit newline guard before tagging
… on unknown runtimes (#361) - resolveRuntime: recognize nodejs24.x, default to nodejs24.x when no runtime is declared, and throw HostingError('UnsupportedRuntimeError') instead of silently falling back to nodejs20.x - add shared FRAMEWORK_COMPUTE_RUNTIME / FRAMEWORK_EDGE_COMPUTE_RUNTIME constants and reference them from the Next.js, Nitro, Astro and SvelteKit adapters instead of hardcoded 'nodejs20.x' literals - keep Lambda@Edge compute on nodejs20.x (documented in framework_runtime.ts) - use DEFAULT_NODE_RUNTIME for the hosting-owned ISR revalidation and tag-table seed handlers - correct the node_runtime.ts scope comment (no framework Node detection exists) - update runtime expectations in tests and cover the throwing path
🦋 Changeset detectedLatest commit: b05160c The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
Lambda@Edge draws its Node.js versions from the same managed runtime table as regional Lambda: nodejs24.x is supported (deprecates 2028-04-30) while nodejs20.x is already past its 2026-04-30 deprecation, so new edge functions can no longer be created on it. Revalidated patchEdgeBundlesForLambdaEdge: the TypeError it works around comes from ES Module namespace exports being non-writable per the ECMAScript spec, not from Node 20 semantics, and the replacement uses only top-level await import() plus the node:process default export - both stable across Node 18-24.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fixes #361. AWS Blocks Hosting was deploying SSR framework Lambdas (Nuxt/Nitro, Astro, SvelteKit, Next.js) on the deprecated
nodejs20.xruntime, andresolveRuntime()silently fell back to Node 20 for any runtime it didn't recognize — masking the problem and making a partial fix ineffective.Changes
framework_runtime.ts):FRAMEWORK_COMPUTE_RUNTIME = 'nodejs24.x'for regional SSR compute andFRAMEWORK_EDGE_COMPUTE_RUNTIME = 'nodejs24.x'for Lambda@Edge. Adapters reference these instead of hardcoded literals, so future bumps are a one-line change.resolveRuntime()now recognizesnodejs24.x, defaults tonodejs24.xwhen no runtime is declared, and throwsUnsupportedRuntimeError(with the list of supported values) instead of silently returningNODEJS_20_X.nitro.ts(both presets),astro.ts,sveltekit.ts,nextjs.ts(regional/server-function and Lambda@Edge paths).node_runtime.tsthat implied the adapters detect the framework's compiled Node version (they don't — the runtime is a fixed shared constant).DEFAULT_NODE_RUNTIMEcontract.Lambda@Edge: also bumped to nodejs24.x
An earlier revision of this PR left the edge path on
nodejs20.xout of caution. That decision has been revised — the edge path is now bumped too:nodejs24.xis supported (deprecates 2028-04-30), whilenodejs20.xis already past its 2026-04-30 deprecation, so it can no longer back newly-created edge functions. Staying on Node 20 was the riskier option.patchEdgeBundlesForLambdaEdgerewrites OpenNext'simport * as process from "node:process"banner. TheTypeError: Cannot assign to read only property 'env' of object '[object Module]'it works around is spec-level behavior — ES Module namespace object bindings are non-writable per ECMA-262 — not a Node 20 quirk. Its replacement (const process = (await import("node:process")).default;) relies only on top-levelawait import(...)and the long-stablenode:processdefault export, both of which behave identically on Node 20, 22, and 24. There is no Node-version-specific assumption in the patch, so no fallback tonodejs22.xwas needed.Code comments in
framework_runtime.tsandnextjs.tswere updated to record this reasoning and to drop the now-inaccurate "Node 20 ESM semantics" framing.Testing
npm run build— clean (tsc --build+ handler bundling), Node 22npm test— 832/832 pass, 0 fail (+3 new tests): default runtime resolves tonodejs24.x; explicitnodejs22.xhonored; unrecognized runtime (python3.12) throwsUnsupportedRuntimeError.nodejs20.x(regional and edge) updated tonodejs24.x.Note:
resolveRuntime()still accepts explicitnodejs20.x/nodejs18.xfrom a user-supplied manifest — this change only moves the framework-emitted defaults.