Node 22 and Azure Functions v4 migration#1593
Conversation
- Bump Node.js from v20 (Iron) to v22 (Jod) LTS - Update Rush from 5.133.4 to 5.166.0 - Update nodeSupportedVersionRange to >=22.0.0 <23.0.0 - Update engine requirements across all packages
- Define type wrappers, guards, and helpers for v4 programming model (HTTP, CosmosDB, EventHub, Timer, Web PubSub) - Export types from main package entry point
- Update adapters to use v4 InvocationContext and HttpResponseInit - Add type definitions, guards, and helpers for all trigger types - Fix parameter property syntax in tests for Node 22 compatibility
This reverts commit ca34a18.
packages/framework-provider-azure-infrastructure/src/infrastructure/index.ts
Fixed
Show fixed
Hide fixed
packages/framework-provider-azure-infrastructure/src/infrastructure/index.ts
Fixed
Show fixed
Hide fixed
packages/framework-provider-azure-infrastructure/src/infrastructure/index.ts
Fixed
Show fixed
Hide fixed
packages/framework-provider-azure-infrastructure/src/infrastructure/index.ts
Fixed
Show fixed
Hide fixed
|
/integration sha=22a37ba |
|
⌛ Integration tests are running... Check their status here 👈 |
|
❌ Oh no! Integration tests have failed |
|
/integration sha=39b572a |
|
⌛ Integration tests are running... Check their status here 👈 |
|
❌ Oh no! Integration tests have failed |
|
/integration sha=9d6ec78 |
|
⌛ Integration tests are running... Check their status here 👈 |
- Bump validator 13.12.0 → 13.15.26, mock-jwks 1.0.3 → 1.0.10 - Add pnpm overrides in .pnpmfile.cjs for transitive vulns - Fix TS7053 in http-service.ts (RequestOptions.headers union type) - Update token verifier tests for jsonwebtoken 9.x iat claim
|
❌ Oh no! Integration tests have failed |
|
/integration sha=9235aca |
|
⌛ Integration tests are running... Check their status here 👈 |
|
✅ Integration tests have finished successfully! |
|
/integration sha=ca63936 |
|
/integration sha=2899da1 |
|
⌛ Integration tests are running... Check their status here 👈 |
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 70 out of 72 changed files in this pull request and generated 14 comments.
Files not reviewed (1)
- website/package-lock.json: Language not supported
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
packages/framework-provider-azure-infrastructure/src/infrastructure/rockets/rocket-builder.ts
Show resolved
Hide resolved
|
✅ Integration tests have finished successfully! |
alvaroloes
left a comment
There was a problem hiding this comment.
claude: ## Node 22 + Azure Functions v4 Migration — Code Review Summary
Overall, this is a solid and well-structured migration. The v3→v4 adapter rewrites are clean, the new type guards in azure-func-types.ts are well-written, and the rocket backward-compat via mountFunctionsV4 alongside deprecated mountCode/mountFunctions is thoughtful. The Web PubSub hub post-deploy update (replacing shell-based curl/az CLI with Azure SDK) is a good improvement.
🔴 Issues to address before merge
.mocharc.yml— missing--prefix (see inline comment)no-experimental-strip-typesneeds to be--no-experimental-strip-types. Without the prefix, Node ignores it and the experimental TS stripping stays active — tests may pass for wrong reasons.scheduled-adapter.ts—isScheduledCommandInputdoesn't validatetypeName(see inline comment)- The type guard only checks
isTimerFunctionInput()butScheduledCommandInputextends it with atypeNamefield. Any timer input will pass, even if it's missingtypeName. pnpmfile.cjs— unbounded security overrides (see inline comment)minSaferanges like'>=4.0.4'are unbounded upward and will match future major versions — contradicting the intent on L38.rocket-builder.ts—functionAppNamesanitization may break Kudu deploy URLs.replace(/(\W+)/gi, '_')converts dashes to underscores, but Azure Function App names use dashes. The sanitized name is used for Kudu deployment URLs (https://${functionAppName}.scm.azurewebsites.net), which would target a non-existent app if the real name has dashes.booster-token-verifier.test.ts—deepEqual→includeweakens assertions- Changing
.to.deep.equals()to.to.deep.include()means the test will pass even ifuser.claimshas extra unexpected properties. If the migration doesn't change claim shapes, the original strict assertion should be preserved. If Node 22 adds extra claim fields, prefer updating the expected object rather than loosening the check.
🟡 Minor issues
events-adapter.ts— typo in error message (see inline comment):AzureCosmosDBFunctioninput→AzureCosmosDBFunctionInputazure-func-types.ts— JSDoc typo (see inline comment):objetc→objecton L11
✅ What looks good
- Type guards (
isHttpFunctionInput,isCosmosDBFunctionInput, etc.) are well-implemented with proper null checks and property existence validation -
- Adapter rewrites (
api-adapter.ts,health-adapter.ts,read-model-adapter.ts,subscription-model.ts) correctly migrate fromContexttoInvocationContext+ typed inputs
- Adapter rewrites (
-
-
booster-graphql-dispatcher.ts— theX-Booster-WebSocket-Messageheader addition is clean and backward-compatible
-
-
-
-
http-service.ts— conditionalContent-Lengthheader is correct
-
-
-
-
-
-
upgrade-v4.mdmigration guide is helpful
-
-
-
-
-
-
-
-
- Terraform Web PubSub hub lifecycle.ignoreChanges pattern is appropriate for post-deploy managed resources
-
-
-
-
-
-
-
-
-
-
- Rush/pnpm tooling version bumps look correct
-
-
-
-
-
packages/framework-provider-azure/src/library/events-adapter.ts
Outdated
Show resolved
Hide resolved
alvaroloes
left a comment
There was a problem hiding this comment.
codex: Revisión completada. He dejado 3 comentarios inline enfocados en riesgos no cubiertos por revisiones previas: 1) deploy que puede terminar en verde con subscriptions rotas si no aparece webpubsub_extension; 2) inconsistencia disconnect/disconnected que puede impedir el path correcto de desconexión; 3) logging excesivo de payload/metadata en connect con riesgo de exponer datos sensibles y aumentar ruido operativo. Recomiendo resolverlos antes de merge.
packages/framework-provider-azure-infrastructure/src/infrastructure/index.ts
Outdated
Show resolved
Hide resolved
...ramework-provider-azure-infrastructure/src/infrastructure/helper/functions-code-generator.ts
Show resolved
Hide resolved
...ramework-provider-azure-infrastructure/src/infrastructure/helper/functions-code-generator.ts
Show resolved
Hide resolved
|
@alvaroloes about this comment: the suggested check is redundant because TypeScript already knows that |
|
/integration sha=1185227c |
|
⌛ Integration tests are running... Check their status here 👈 |
|
✅ Integration tests have finished successfully! |
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 70 out of 72 changed files in this pull request and generated 4 comments.
Files not reviewed (1)
- website/package-lock.json: Language not supported
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Description
This PR adds Node 22 support for Booster. Booster 3.x works with Node 20, which is reaching EOL in April 2026. In the case of Azure, switching to Node 22 requires upgrading the Azure Functions runtime from v3 to v4. Version 4 introduces an imperative approach instead of a declarative one—functions are now defined programmatically in a
functions.jsfile rather than thefunction.jsonfiles used in v3.Another major change in the v4
@azure/functionsSDK is the context type used in function requests (Context→InvocationContext). Wrappers were created for the different types of function requests.Changes
framework-provider-azure-infrastructurepackage to generate v4-compatible Azure Functionsframework-provider-azureto work with the v4@azure/functionsSDKChecks
Additional information
Rockets targeting Azure infrastructure must be updated to implement
mountFunctionsV4instead of the now-deprecatedmountCodeandmountFunctionsmethods. See the migration guide for details.