chore: add automated npm release tooling - #72
Conversation
- Add np package for interactive releases - Add prepublishOnly script to run tests/lint/build before publish - Add GitHub Actions workflow to auto-publish on tag push - Configure .nprc for release settings
|
Note Other AI code review bot(s) detectedCodeRabbit has detected other AI code review bot(s) in this pull request and will avoid duplicating their findings in the review comments. This may lead to a less comprehensive review. WalkthroughAdds automated npm publishing: a GitHub Actions workflow that runs on pushed tags matching v* to lint, build, test, verify artifacts, and publish to npm; introduces Changes
Sequence Diagram(s)sequenceDiagram
participant Dev as Maintainer
participant GH as GitHub (tags)
participant Actions as GitHub Actions (publish workflow)
participant Registry as npm
Dev->>GH: Push tag "vX.Y.Z"
GH->>Actions: Trigger on tag push (v*)
rect rgb(220,235,255)
Actions->>Actions: Checkout + verify tag format
Actions->>Actions: Setup Node.js & npm registry
Actions->>Actions: Install deps, run audit (warn on high), lint, build, test
Actions->>Actions: Verify dist artifacts and required files
Actions->>Actions: Ensure tag version == package.json version
end
rect rgb(200,255,200)
Actions->>Registry: Publish package (provenance, public) using NPM_TOKEN
Registry-->>Actions: Publish result
end
Actions->>GH: Create GitHub Release (script)
GH-->>Dev: Release created / publish status
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes
Poem
Pre-merge checks and finishing touches✅ Passed checks (3 passed)
✨ Finishing touches🧪 Generate unit tests (beta)
Comment |
Summary of ChangesHello @hideokamoto, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request automates and standardizes the npm package release process by incorporating the 'np' tool and establishing mandatory pre-publish checks. This ensures that every new package version is thoroughly validated before being published, enhancing the overall reliability and consistency of releases. Highlights
Ignored Files
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
There was a problem hiding this comment.
Code Review
This pull request introduces tooling for automated npm releases using the np package, which is a great step towards streamlining the release process. The configuration includes adding np as a dev dependency, setting up scripts in package.json, and providing an .nprc configuration file.
My review has identified a critical security issue and a minor redundancy:
- Security: The
.nprcfile disables two-factor authentication (2FA) for publishing, which is a significant security risk. I've left a comment with a suggestion to address this. - Redundancy: The
prepublishOnlyscript runs tests, whichnpalso does by default, leading to tests running twice. I've suggested a change to avoid this.
Additionally, the pull request description mentions adding a GitHub Actions workflow for auto-publishing on tag push, but this file seems to be missing from the changes. Please ensure it's included to complete the automated release setup.
| { | ||
| "yarn": false, | ||
| "anyBranch": false, | ||
| "2fa": false, |
There was a problem hiding this comment.
Disabling two-factor authentication (2FA) for publishing ("2fa": false) is a critical security risk. If your npm credentials are ever compromised, an attacker could publish malicious versions of your package. It is strongly recommended to enable 2FA on your npm account and require it for publishing.
"2fa": true,
| "format": "biome format --write .", | ||
| "prepare": "husky" | ||
| "prepare": "husky", | ||
| "prepublishOnly": "npm run lint && npm run build && npm test", |
There was a problem hiding this comment.
The np tool runs npm test by default before publishing. Since your prepublishOnly script also runs npm test, the tests will be executed twice during a release. To avoid this redundancy, I suggest removing npm test from this script and letting np handle the testing step.
| "prepublishOnly": "npm run lint && npm run build && npm test", | |
| "prepublishOnly": "npm run lint && npm run build", |
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Nitpick comments (1)
.github/workflows/publish.yml (1)
26-36: Consider consolidating pre-publish steps with npm hooks.The workflow manually runs
npm run lint,npm run build, andnpm testbefore publishing. These are also defined in theprepublishOnlyhook in package.json (line 33). The GitHub Actions workflow does not use thereleasescript or invoke the prepublishOnly hook; instead, it duplicates the logic.This duplication can lead to inconsistency if one set of commands is updated without the other. Consider simplifying the workflow to leverage the release process defined in package.json:
- name: Install dependencies run: npm ci - name: Release run: npm run release env: NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }} NPM_PUBLISH_TOKEN: ${{ secrets.NPM_TOKEN }}Alternatively, if you prefer explicit control, document why the workflow does not use the
releasescript.Note: The
nptool has its own hooks and configuration; verify that--provenance --access publicflags are compatible withnp's publish command. You may need to add these flags to.nprcor invokenpwith additional CLI arguments.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (2)
package-lock.jsonis excluded by!**/package-lock.jsonyarn.lockis excluded by!**/yarn.lock,!**/*.lock
📒 Files selected for processing (3)
.github/workflows/publish.yml(1 hunks).nprc(1 hunks)package.json(3 hunks)
🧰 Additional context used
🪛 GitHub Actions: CI
package.json
[error] 16-19: Formatter would have adjusted package.json formatting (files array). Run 'biome format .' to fix.
🔇 Additional comments (5)
package.json (2)
33-34: Verify prepublishOnly hook covers all pre-release validation.The prepublishOnly script properly chains commands with
&&to ensure that failure at any step (lint, build, or test) prevents publication. However, this is also replicated in the GitHub Actions workflow, which runs the same commands again.Confirm:
- Is the redundant test/lint/build in the CI workflow intentional, or should the workflow use
npm run releaseto leverage the prepublishOnly hook?- The
releasescript invokesnp, which has its own hooks and logic—verify thatnp's configuration in.nprcaligns with the intended workflow.Consider whether the GitHub Actions workflow should be simplified to invoke
npm run releaseinstead of manually running individual scripts, or document why the explicit separation is preferred.
49-49: No issues found — thenppackage is current and secure.The latest version of the
nppackage is 10.2.0, which matches the version specified in package.json. No security advisories have been identified for this package..github/workflows/publish.yml (3)
1-6: Verify tag naming convention is enforced.The workflow triggers on tags matching the pattern
v*, which is a common convention for semantic versioning. However, there is no validation that the tag follows semantic versioning (e.g.,v1.2.3). A malformed tag could trigger the workflow and result in an incorrect package version.Confirm that:
- Your repository has branch protection rules or tagging conventions that enforce valid semantic version tags
- The
nptool in.nprcis configured to validate tag format before publishingAlternatively, consider adding a validation step to ensure the tag matches a strict semver pattern:
- name: Validate tag format run: | if [[ ! "${{ github.ref }}" =~ ^refs/tags/v[0-9]+\.[0-9]+\.[0-9]+(-[a-zA-Z0-9.]+)?$ ]]; then echo "Invalid tag format: ${{ github.ref }}" exit 1 fi
11-13: LGTM on minimal permissions.The permissions are properly scoped to
contents: readandid-token: write. The latter is necessary for npm's provenance feature, which is good security practice. The settings follow the principle of least privilege.
38-41: Verify NPM_TOKEN secret is configured and that provenance settings are compatible with np.The workflow uses
--provenanceand--access publicflags fornpm publish. These are standard npm CLI flags, but verify that they work correctly with thenptool and thatnpis not being invoked directly (since the current workflow usesnpm publish).Confirm:
- The
NPM_TOKENsecret is configured in the GitHub repository settings- If
npis meant to be used (as defined in thereleasescript), verify that the flags--provenanceand--access publicare compatible withnp's publish command, or move them to.nprcYou may also want to verify that the Node.js authentication is properly set up. Consider testing this workflow in a staging environment or using GitHub's workflow visualization to debug any issues.
Also, note that
registry-urlis set in the Node.js setup (line 23), which should handle npm authentication correctly whenNODE_AUTH_TOKENis provided.
| - name: Publish to npm | ||
| run: npm publish --provenance --access public | ||
| env: | ||
| NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }} |
There was a problem hiding this comment.
Critical: Missing NPM_CONFIG_PROVENANCE environment variable for provenance signing.
npm provenance requires the NPM_CONFIG_PROVENANCE environment variable set to true in the GitHub Actions workflow, in addition to the --provenance flag. Without this environment variable, provenance signing may not be properly configured.
Add the missing environment variable:
- name: Publish to npm
run: npm publish --provenance --access public
env:
NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}
+ NPM_CONFIG_PROVENANCE: trueAdditionally, npm classic token creation is now disabled as of November 19, 2025, and you should migrate to trusted publishing or granular access tokens to avoid disruption. Consider migrating from long-lived tokens to trusted publishers which use short-lived, scoped credentials that eliminate the need for long-lived tokens and reduce security risks.
🤖 Prompt for AI Agents
.github/workflows/publish.yml around lines 38 to 41: the Publish to npm step is
missing the NPM_CONFIG_PROVENANCE environment variable required for npm
provenance signing; add NPM_CONFIG_PROVENANCE set to "true" to the step's env
block so the --provenance flag works as intended, and keep NODE_AUTH_TOKEN
as-is; additionally, plan to migrate from classic long-lived tokens to trusted
publishers or granular access tokens and update workflow secrets accordingly.
| { | ||
| "yarn": false, | ||
| "anyBranch": false, | ||
| "2fa": false, | ||
| "contents": ".", | ||
| "cleanup": true | ||
| } |
There was a problem hiding this comment.
Disable 2FA requirement in .nprc introduces security risk.
The setting "2fa": false disables npm's 2-factor authentication verification for releases. This weakens the security posture when publishing packages, as it removes an important protection against account compromise or unauthorized releases.
Enable 2FA verification to strengthen package security:
{
"yarn": false,
"anyBranch": false,
- "2fa": false,
+ "2fa": true,
"contents": ".",
"cleanup": true
}If there are operational reasons for disabling 2FA here, consider implementing compensating controls such as:
- GitHub branch protections requiring approval before tag pushes
- IP allow-lists on the GitHub organization or npm account
- Audit logging and alerts on all releases
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| { | |
| "yarn": false, | |
| "anyBranch": false, | |
| "2fa": false, | |
| "contents": ".", | |
| "cleanup": true | |
| } | |
| { | |
| "yarn": false, | |
| "anyBranch": false, | |
| "2fa": true, | |
| "contents": ".", | |
| "cleanup": true | |
| } |
🤖 Prompt for AI Agents
.nprc lines 1-7: the config currently sets "2fa": false which disables npm
two-factor auth for releases; change this to enable 2FA by setting "2fa": true
(or remove the key so the default enforces 2FA) and update release docs to
require personal or org-level 2FA for any account that publishes; if there are
operational constraints that prevent enabling 2FA, implement compensating
controls such as branch protections preventing direct tag pushes, IP allow-lists
for CI/publish runners, and alerting/audit logging for all publish events and
document those exceptions.
| "files": [ | ||
| "dist", | ||
| "src" | ||
| ], |
There was a problem hiding this comment.
Fix formatting failure in files array.
The pipeline reports that Biome formatter would adjust the formatting of the files array. The array is currently formatted on multiple lines, but Biome expects a different format.
Run biome format . to fix the formatting issue before merging:
biome format .Alternatively, if you want to manually apply the fix, use the biome format --write . command or reformat inline:
- "files": [
- "dist",
- "src"
- ],
+ "files": ["dist", "src"],🧰 Tools
🪛 GitHub Actions: CI
[error] 16-19: Formatter would have adjusted package.json formatting (files array). Run 'biome format .' to fix.
🤖 Prompt for AI Agents
In package.json around lines 16 to 19, the "files" array is formatted across
multiple lines which the Biome formatter will change; run "biome format ." (or
"biome format --write .") to reformat the file so the files array matches the
project's Biome style, or manually reformat the array to the expected
single-line style and commit the updated package.json.
- Add environment protection requiring manual approval - Verify tag format and version matching - Validate package-lock.json integrity - Audit dependencies before publish - Verify build artifacts completeness - Pin GitHub Actions to SHA hashes - Add comprehensive security documentation
There was a problem hiding this comment.
Actionable comments posted: 0
♻️ Duplicate comments (1)
.github/workflows/publish.yml (1)
93-96: [DUPLICATE] Add NPM_CONFIG_PROVENANCE environment variable.npm provenance requires the NPM_CONFIG_PROVENANCE environment variable to be set to true in addition to the
--provenanceflag. Without this environment variable, provenance signing may not be properly configured.Apply this diff:
- name: Publish to npm run: npm publish --provenance --access public env: NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }} + NPM_CONFIG_PROVENANCE: true
🧹 Nitpick comments (3)
SECURITY.md (1)
44-50: Add language specification to all fenced code blocks.Lines 44, 53, 61, 69, 104, and 127 contain fenced code blocks without a language identifier. Add
bash,json, or other appropriate language tags for consistency with markdown best practices and linter requirements.Apply this diff to the first instance (line 44) and repeat for other code blocks:
- ``` + ```bash Settings → Branches → Add rule.github/workflows/publish.yml (1)
93-96: Plan migration away from classic npm tokens.npm classic token creation is now disabled and existing classic tokens will be revoked on November 19, 2025. Migrate to trusted publishing or granular access tokens to avoid disruption. While the current workflow uses
NODE_AUTH_TOKENwith a long-lived secret, consider migrating to trusted publishing, which eliminates security risks by using short-lived, workflow-specific credentials that are automatically managed and cannot be extracted.README.md (1)
159-163: Add language specification to fenced code blocks.Lines 159 and 166 contain fenced code blocks without a language identifier. These should be marked as
bashto match markdown linting standards.Apply this diff:
1. **Configure npm-publish environment** in GitHub: - ``` + ```bash Settings → Environments → New environment: "npm-publish"And similarly for line 166:
2. **Add NPM_TOKEN secret**: - ``` + ```bash Settings → Secrets → New repository secret
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
.github/workflows/publish.yml(1 hunks)README.md(1 hunks)SECURITY.md(1 hunks)
🧰 Additional context used
🪛 markdownlint-cli2 (0.18.1)
SECURITY.md
44-44: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
53-53: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
61-61: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
69-69: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
104-104: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
127-127: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
README.md
159-159: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
166-166: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
Summary by CodeRabbit
Chores
Documentation
Security