fix: pnpm publish auth — write .npmrc explicitly#45
Merged
Conversation
setup-node's .npmrc template uses ${NODE_AUTH_TOKEN} which npm
expands but pnpm doesn't pick up reliably. Write the auth token
to ~/.npmrc directly before pnpm publish.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
✅ Files skipped from review due to trivial changes (1)
📝 WalkthroughWalkthroughThe release workflow now writes the npm registry auth token into Changes
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~3 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
🧹 Nitpick comments (2)
.github/workflows/release-please.yml (2)
92-92: Avoid duplicate provenance configuration.Line 92 duplicates the
--provenanceflag already present in the publish command (Line 89). Keep one source of truth to reduce drift.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/release-please.yml at line 92, The workflow currently sets NPM_CONFIG_PROVENANCE: true which duplicates the --provenance flag already passed to the npm publish command; remove the redundant environment variable (NPM_CONFIG_PROVENANCE) so provenance is controlled only via the publish command flag, leaving the existing --provenance usage intact to avoid configuration drift.
83-83: Harden.npmrcfile permissions when writing token.On Line 83, consider creating the file with restrictive permissions (0600) before writing the token.
Suggested change
- - name: Configure npm auth - run: echo "//registry.npmjs.org/:_authToken=${NPM_TOKEN}" > ~/.npmrc + - name: Configure npm auth + run: | + umask 077 + printf '%s\n' "//registry.npmjs.org/:_authToken=${NPM_TOKEN}" > ~/.npmrc env: NPM_TOKEN: ${{ secrets.NPM_TOKEN }}🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/release-please.yml at line 83, The step that writes the NPM token currently uses the command string 'echo "//registry.npmjs.org/:_authToken=${NPM_TOKEN}" > ~/.npmrc' which leaves default file perms; change it to create the file with restrictive 0600 permissions before/when writing the token (for example, set umask 077 for the write or create then chmod 600 the file). Update the workflow run command that contains the echo/redirect so it either prefixes with 'umask 077 &&' or writes then runs 'chmod 600 ~/.npmrc' to ensure ~/.npmrc is only readable/writable by the owner.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In @.github/workflows/release-please.yml:
- Line 92: The workflow currently sets NPM_CONFIG_PROVENANCE: true which
duplicates the --provenance flag already passed to the npm publish command;
remove the redundant environment variable (NPM_CONFIG_PROVENANCE) so provenance
is controlled only via the publish command flag, leaving the existing
--provenance usage intact to avoid configuration drift.
- Line 83: The step that writes the NPM token currently uses the command string
'echo "//registry.npmjs.org/:_authToken=${NPM_TOKEN}" > ~/.npmrc' which leaves
default file perms; change it to create the file with restrictive 0600
permissions before/when writing the token (for example, set umask 077 for the
write or create then chmod 600 the file). Update the workflow run command that
contains the echo/redirect so it either prefixes with 'umask 077 &&' or writes
then runs 'chmod 600 ~/.npmrc' to ensure ~/.npmrc is only readable/writable by
the owner.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 3027ecac-ee41-4e37-a629-0878903218a1
📒 Files selected for processing (1)
.github/workflows/release-please.yml
--provenance flag on pnpm publish already controls this.
5 tasks
4 tasks
27Bslash6
added a commit
that referenced
this pull request
May 17, 2026
…2 release (#52) ## Summary Two real documentation fixes that double as the trigger commit for the 0.1.2 recovery release. ### `packages/cachekit/README.md` - `Requirements: Node.js 18+` was stale. PR #47 bumped `engines.node` to `>=22.0.0` across all packages. README now matches: `Node.js 22+`. - Added a short version-history note explaining the `0.1.0 → 0.1.2` jump on npm so consumers don't think 0.1.1 is missing or yanked. ### `packages/cachekit-core-ts/README.md` (new) Every npm-published package should have a README. This one didn't. Added a minimal one covering: - What the package is and that consumers shouldn't install it directly - The 5 prebuilt platform packages and how `optionalDependencies` selects one - A summary of the public N-API surface - The same 0.1.0 → 0.1.2 version note ## Why this is the bootstrap commit for 0.1.2 The commit touches both `packages/cachekit/` and `packages/cachekit-core-ts/` paths so release-please picks both packages up for a coordinated release. The `Release-As: 0.1.2` trailer skips 0.1.1 (which exists as a git tag but never reached npm) and forces release-please to propose 0.1.2 directly. Type is `docs:` because that's what the changes honestly are — no code behavior changes. The `Release-As:` trailer is what triggers the release, not the type. ## What happens after this merges 1. release-please.yml fires on push to main 2. release-please scans commits since the last published manifest, sees the `Release-As: 0.1.2` trailer and the path touches → opens a release PR titled `chore: release main` proposing 0.1.2 for both packages 3. Merging that release PR cuts tags `cachekit-v0.1.2` and `cachekit-core-ts-v0.1.2` 4. `release-please.yml publish-cachekit` runs (auth fix from PR #45 is in place) → publishes `@cachekit-io/cachekit@0.1.2` 5. The core-ts tag triggers `build-native.yml` → publishes `@cachekit-io/cachekit-core-ts@0.1.2` + creates all 5 platform packages on npm (napi flag fix from PR #51 is in place) After step 5, all 7 packages exist on npm — at which point you can: 6. Configure trusted publishers on npmjs.com for each 7. Take PR #50 out of draft and merge it 8. Delete the `NPM_TOKEN` repo secret after the next OIDC-based release confirms the loop ## Fallback if release-please ignores `Release-As:` on a `docs:` commit If release-please's defaults don't pick up `Release-As:` from a non-releasing commit type, the fallback is to: - Bump both `package.json` files to 0.1.2 directly - Update `.release-please-manifest.json` to 0.1.2 for both packages - Manually create and push the tags I'd open that as a follow-up PR if needed — keeping the doc-fix and the release-trigger separate. ## Test plan - [x] Local validation via prek (no hooks affected by markdown-only changes) - [ ] CI green on this PR - [ ] After merge: confirm release-please opens a 0.1.2 PR within a few minutes - [ ] Merge the release PR and watch both publish workflows go green <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Added comprehensive documentation for the native binding package, including installation guidance and platform support details * Updated minimum Node.js version requirement to 22+ * Clarified version and release information <!-- review_stack_entry_start --> [](https://app.coderabbit.ai/change-stack/cachekit-io/cachekit-ts/pull/52?utm_source=github_walkthrough&utm_medium=github&utm_campaign=change_stack) <!-- review_stack_entry_end --> <!-- end of auto-generated comment: release notes by coderabbit.ai -->
](https://app.coderabbit.ai/change-stack/cachekit-io/cachekit-ts/pull/52?utm_source=github_walkthrough&utm_medium=github&utm_campaign=change_stack){kind=link}
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.
Problem
Release workflow failed with
ENEEDAUTH—pnpm publishdoesn't reliably pick up the${NODE_AUTH_TOKEN}template thatsetup-nodewrites to.npmrc.Fix
Write
//registry.npmjs.org/:_authTokendirectly to~/.npmrcbeforepnpm publish. This ensures pnpm has explicit auth regardless of.npmrcresolution order.Context
This blocked the v0.1.1 release (run 24957354685). After merge, re-trigger by running the Release workflow manually or pushing a new
fix:commit.Summary by CodeRabbit