Verify: npm token is granular (not classic) before next release

[mroderick]

Background

PR #159 enabled npm provenance attestations. Provenance requires a Granular Access Token — classic tokens do not support provenance and are being deprecated by npm.

Using a classic token would silently break provenance: the publish would succeed, but no attestation would be generated. The package would be published without the security guarantees that provenance provides.

Goal

Verify that the npm token used in the NPM_TOKEN GitHub secret is a Granular Access Token scoped specifically to @idempot-dev, not a Classic token.

When to do this

Before the next release. If the token is classic, the next release will publish packages without provenance. This is a silent failure — the publish succeeds but the security feature is absent.

Verification steps

Step 1: Check token type in npm UI

1. Log in to https://www.npmjs.com/ with the account that owns the @idempot-dev organization
2. Go to Access Tokens (click your profile → Access Tokens)
3. Look for the token used by the NPM_TOKEN GitHub secret
4. Verify it says "Granular Access Token" (not "Classic Token")

Step 2: Verify token scope

The token should be scoped to:

• Packages: @idempot-dev/*
• Permissions: Publish
• Organizations: idempot-dev

It should NOT be a "Read and publish" token for your personal account — that would be a classic token.

Step 3: Verify token is active and not expired

Granular tokens have expiration dates. Check that the token is still active and not approaching expiry.

If the token is classic

Action required

1. Create a new Granular Access Token:

   • Go to npm → Access Tokens → Generate New Token → Granular Access Token
   • Name: idempot-js-release-provenance
   • Packages: @idempot-dev/*
   • Permissions: Publish
   • Expiration: Set a reasonable expiry (e.g., 1 year) with a calendar reminder

2. Update the GitHub secret:

   • Go to https://github.com/idempot-dev/idempot-js/settings/secrets/actions
   • Update NPM_TOKEN with the new token value
   • Delete the old classic token from npm to prevent accidental use

3. Test the token:

   • The only way to fully test is through the release workflow
   • Consider a test publish to a private/unpublished package or a dry-run

Why this matters

Token type	Provenance support	Deprecation status	Security
Classic	❌ No	Being deprecated by npm	Lower (full account access)
Granular	✅ Yes	Current standard	Higher (scoped to specific packages)

Related

• PR ci: enable npm provenance attestations #159 — "ci: enable npm provenance attestations"
• Issue Verify: npm provenance attestations after next release #165 — "Verify npm provenance after next release"
• npm docs: Creating granular access tokens