CLOUDPLAT-3162: add npm OIDC publish workflow (s3scan)

[haseebehsan]

Summary

Adds the reusable workflow-npm-oidc-publish workflow from mapbox/gha-public.

This replaces local/manual npm publish with a GitHub Actions workflow using OIDC Trusted Publishing — no npm tokens required.

Trigger: manual (workflow_dispatch) — run from the Actions tab to publish.

Ticket: https://mapbox.atlassian.net/browse/CLOUDPLAT-3162

[ox-security]

Successfully scanned changes introduced in a pull request into master from cloudplat-3162/add-npm-oidc-publish.

Internal scan identifier: 7cfedbf5-849e-4ce5-9cfc-23a945c6a0b2.

Total issues	Blocking issues	Scan status
1	0	✔️

Category	Issues
CI/CD Posture	1

See all issues found during this scan in the OX Security Application.

Detailed information

Issue #	1
Name	Unpinned Reusable Workflow • GitHub Actions
Status	New
Enforcement	Monitor
Severity	High
Category	CI/CD Posture
Source tools	OX CI/CD Posture
Recommendation	Pin reusable workflows to a full-length commit SHA (40 characters) instead of a tag or branch. Example: uses: org/repo/.github/workflows/build.yml@a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0

1 aggregation

File	Match
.github/workflows/npm-release.yml	uses: mapbox/gha-public/.github/workflows/workflow-npm-oidc-publish.yml@main

[mourner]

There's no CHANGELOG.md in most of the repos this PR template was submitted to — the more common practice is to maintain changelogs in the GitHub Releases section, so this item doesn't make sense.

[mourner]

The workflow already passes the public tag (npm publish --access public), so this change is fully redundant.

[mourner]

There is zero reason to bump versions in this PR template because changing the workflow does not change the package contents itself — instead of asking every receiver of these PRs to "remove the bump if you don't need it" (which is a lot of manual labor), it should have been the other way around (but I really can't think of any reason such a PR would need a version bump, except to test out the workflow immediately with a vain version).

[mourner]

ox-security is right — it's fragile to have this unpinned / not versioned; even an inconspicuous-looking update of the workflow can break releases across hundreds of repos.

[mourner]

This might make sense for private packages, but it's a questionable default for public projects, where it's important to have release notes written with care, not auto-generated from commits.

[mourner]

If we want to follow common practices, a release should be 1) tagged, 2) marked with a clear semver commit. So npm version is a more universal instruction.

[mourner]

This whole note feels redundant. Does it really need clarification that external PR authors can't publish NPM releases by themselves, and only package maintainers can actually do that?

[mourner]

Also a few comments on the workflow itself to keep my feedback in one review:

• Node version should be v24, the current LTS. v22 is in maintenance mode. Subsequently, there'd be no need to do npm install -g npm@^11.5.1 because v24 comes with v11.6.0+ bundled.
• "Run tests" and "Build package" should not be in the workflow. Gating and preparing assets before publish is the responsibility of prepublishOnly hook in package.json.
• "Build package" runs unconditionally, which makes it run twice if a package does have prepublishOnly set up properly.

[mourner]

In general this workflow seems redundant as a whole. You have a 146-line boilerplate running typical workflow things like npm ci and tests with a lot of verbose options, but there's no value in it being reusable because you can replace the composition of this uses workflow and the dependency with a compact 17-line self-sufficient workflow that is much easier to maintain and less fragile. This push was about switching to OIDC publishing specifically, so it doesn't warrant pushing projects towards more complicated workflows with logic unrelated to OIDC.