build: migrate npm releases to shared ESRP template

[Tsuyoshi Ushio (TsuyoshiUshio)]

Summary

• migrate real npm publishing in the stable release.yml pipeline to the shared engineering /ci/release-npm-package.yml@eng template with publishMethod: esrp
• keep dry runs local and non-publishing with the repository's tag/version validation plus npm publish --dry-run --ignore-scripts
• leave the existing pre-release pipeline and its publishing behavior unchanged
• document the Azure DevOps and npm operational setup

This follows the shared ESRP npm release pattern introduced in Azure/azure-functions-skills#213 and its current main pipeline definitions.

Validation

• npm test
• npm run build
• parsed all changed YAML with js-yaml
• checked changed templates/docs with the repository Prettier configuration
• packed @azure/functions@4.16.3, ran validateRelease for the latest tag, and completed npm publish --dry-run --ignore-scripts against registry.npmjs.org
• confirmed pre-release.yml and its existing npm publish template are unchanged from v4.x

Operational setup required

Before running release.yml with NpmPublishDryRun: false:

• create the azure-functions-nodejs-library-release variable group with EsrpOwners, EsrpApprovers, and EsrpManualApprovers; owners and approvers must be individual Microsoft aliases and must not overlap
• authorize the release pipeline to use that variable group, the internal engineering repository resource at refs/tags/release, the ESRP service connection, and the nodejs-library.official pipeline resource
• add microsoft1es and microsoft-oss-releases as read/write collaborators for the @azure/functions npm package

[Swapnil Nagar (swapnil-nagar)]

PR Review — build: migrate npm releases to shared ESRP template

Thanks Tsuyoshi Ushio (@TsuyoshiUshio), overall this is a clean migration to the shared ESRP release flow and mirrors the companion change in azure-functions-nodejs-extensions (#154). LGTM in principle. A few observations and questions:

Looks good

• Splitting release.yml into a ValidateRelease (dry-run) job vs. real publish via the shared /ci/release-npm-package.yml@eng template with publishMethod: esrp is a nice separation, and defaulting NpmPublishDryRun: true is the safe default.
• The single-.tgz guard in npm-publish-dry-run-steps.yml (throw when count != 1) is a good safety check.
• README documents the variable group (EsrpOwners/EsrpApprovers/EsrpManualApprovers) and collaborator setup clearly.

Questions / suggestions

1. Node version drift: the dry-run step here pins NodeTool@0 to 20.x, while the extensions repo PR (Wrong order of arguments in release of 4.0.0 #154) uses 22.x. Is the difference intentional (matching each repo''s supported runtime), or should these be aligned?
2. Orphaned template: release.yml no longer references azure-pipelines/templates/npm-publish-steps.yml. If it''s now unused, should it be removed in this PR to avoid dead config?
3. Dry-run publishing safety: confirming the --dry-run --ignore-scripts npm publish never authenticates against ESRP — from the diff the dry-run path only hits the public registry, which is correct; just calling it out for reviewers.

Nothing blocking from my side once the Node version question and the orphaned template are addressed.

[Tsuyoshi Ushio (TsuyoshiUshio)]

Swapnil Nagar (@swapnil-nagar) Thanks for the review. I checked both points:

1. Node 20 is intentional for this repository. package.json declares node >=20.0, and the regular build template also uses Node 20.x, so the dry-run release validation matches this repository's supported runtime and build environment.
2. azure-pipelines/templates/npm-publish-steps.yml is not orphaned. It is still referenced by azure-pipelines/pre-release.yml for the pre-release flow, so it should remain.

Also confirmed that the dry-run publish explicitly targets the public npm registry and uses both --dry-run and --ignore-scripts; ESRP is only used by the non-dry-run shared release template. Based on these checks, no code change is needed for these comments.