P1: NPM publish pipeline + package contents control#40
Merged
Kinin-Code-Offical merged 1 commit intomainfrom Dec 22, 2025
Merged
P1: NPM publish pipeline + package contents control#40Kinin-Code-Offical merged 1 commit intomainfrom
Kinin-Code-Offical merged 1 commit intomainfrom
Conversation
Reviewer's GuideAdds an automated GitHub Actions workflow to publish the package to npm on releases/manual dispatch, and restricts the published package contents via a package.json files whitelist. Sequence diagram for GitHub release-triggered npm publish workflowsequenceDiagram
actor Maintainer
participant GitHub
participant Workflow_npm_publish
participant Node_environment
participant npm_registry
Maintainer->>GitHub: Create release with tag vX.Y.Z
GitHub-->>Workflow_npm_publish: Trigger release published event
Workflow_npm_publish->>Workflow_npm_publish: Set RELEASE_TAG from github.event.release.tag_name
Workflow_npm_publish->>GitHub: actions_checkout ref RELEASE_TAG
Workflow_npm_publish->>Node_environment: actions_setup_node with node 22.x and npm registry
Workflow_npm_publish->>Node_environment: npm ci
Workflow_npm_publish->>Node_environment: Check Version script
Node_environment-->>Workflow_npm_publish: Validate tag matches package.json version
Workflow_npm_publish->>Node_environment: npm run build
Workflow_npm_publish->>npm_registry: npm publish --access public using NODE_AUTH_TOKEN
npm_registry-->>Workflow_npm_publish: Publish result
Workflow_npm_publish-->>Maintainer: Workflow status and npm publish outcome
File-Level Changes
Assessment against linked issues
Possibly linked issues
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
There was a problem hiding this comment.
Hey - I've found 1 issue, and left some high level feedback:
- In the
envdefinition forRELEASE_TAG, the expression usesinputs.tag, which is not a valid context forworkflow_dispatch; you likely wantgithub.event.inputs.taginstead so that manual dispatch reads the provided tag correctly. - Consider adding a
npm pack --dry-runstep beforenpm publishto validate thefileswhitelist and resulting tarball contents, which will help catch accidental omissions from the package.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- In the `env` definition for `RELEASE_TAG`, the expression uses `inputs.tag`, which is not a valid context for `workflow_dispatch`; you likely want `github.event.inputs.tag` instead so that manual dispatch reads the provided tag correctly.
- Consider adding a `npm pack --dry-run` step before `npm publish` to validate the `files` whitelist and resulting tarball contents, which will help catch accidental omissions from the package.
## Individual Comments
### Comment 1
<location> `.github/workflows/npm-publish.yml:20-25` </location>
<code_context>
+ permissions:
+ contents: read
+ env:
+ RELEASE_TAG: ${{ github.event_name == 'workflow_dispatch' && inputs.tag || github.event.release.tag_name }}
+ steps:
+ - uses: actions/checkout@v4
</code_context>
<issue_to_address>
**suggestion (bug_risk):** Tighten validation of `RELEASE_TAG` when triggered via `workflow_dispatch` to avoid publishing from an arbitrary ref.
Since `inputs.tag` is user-supplied, this lets a `workflow_dispatch` caller point checkout at any ref name they choose, not necessarily a real tag or one following your scheme. That means you can publish from a commit that isn’t actually referenced by a Git tag, even though you later compare the version to `package.json`. To avoid this, either validate that `inputs.tag` corresponds to an existing tag (e.g. `git rev-parse --verify refs/tags/$TAG`) or rely on `github.ref_name` only for release events and restrict `workflow_dispatch` to selecting from existing tags.
```suggestion
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 0
- name: Validate release tag exists (workflow_dispatch only)
if: github.event_name == 'workflow_dispatch'
run: |
git rev-parse --verify "refs/tags/${RELEASE_TAG}"
- name: Check out release tag
run: |
git checkout "refs/tags/${RELEASE_TAG}"
- name: Use Node.js 22.x
```
</issue_to_address>Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
Comment on lines
+20
to
+25
| steps: | ||
| - uses: actions/checkout@v4 | ||
| with: | ||
| ref: ${{ env.RELEASE_TAG }} | ||
|
|
||
| - name: Use Node.js 22.x |
There was a problem hiding this comment.
suggestion (bug_risk): Tighten validation of RELEASE_TAG when triggered via workflow_dispatch to avoid publishing from an arbitrary ref.
Since inputs.tag is user-supplied, this lets a workflow_dispatch caller point checkout at any ref name they choose, not necessarily a real tag or one following your scheme. That means you can publish from a commit that isn’t actually referenced by a Git tag, even though you later compare the version to package.json. To avoid this, either validate that inputs.tag corresponds to an existing tag (e.g. git rev-parse --verify refs/tags/$TAG) or rely on github.ref_name only for release events and restrict workflow_dispatch to selecting from existing tags.
Suggested change
| steps: | |
| - uses: actions/checkout@v4 | |
| with: | |
| ref: ${{ env.RELEASE_TAG }} | |
| - name: Use Node.js 22.x | |
| steps: | |
| - uses: actions/checkout@v4 | |
| with: | |
| fetch-depth: 0 | |
| - name: Validate release tag exists (workflow_dispatch only) | |
| if: github.event_name == 'workflow_dispatch' | |
| run: | | |
| git rev-parse --verify "refs/tags/${RELEASE_TAG}" | |
| - name: Check out release tag | |
| run: | | |
| git checkout "refs/tags/${RELEASE_TAG}" | |
| - name: Use Node.js 22.x |
There was a problem hiding this comment.
Pull request overview
This PR adds automated npm package publishing functionality and controls what gets included in the published package. The workflow is triggered either automatically when a GitHub release is published or manually via workflow dispatch, and includes version validation to ensure package.json version matches the release tag.
Key changes:
- Added npm publish GitHub Actions workflow with release and manual triggers
- Configured package.json
fileswhitelist to control npm package contents (dist, README.md, LICENSE, CHANGELOG.md)
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| package.json | Added files array to whitelist package contents for npm publish |
| .github/workflows/npm-publish.yml | New workflow automating npm package publishing with version validation and build steps |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| contents: read | ||
| env: | ||
| RELEASE_TAG: ${{ github.event_name == 'workflow_dispatch' && inputs.tag || github.event.release.tag_name }} | ||
| steps: |
There was a problem hiding this comment.
When using workflow_dispatch, the workflow attempts to checkout a tag that might not exist yet. If someone manually triggers this workflow with a tag that hasn't been pushed, the checkout step will fail. Consider adding validation to ensure the tag exists, or document that the tag must be pushed before manually triggering this workflow.
Suggested change
| steps: | |
| steps: | |
| - name: Validate tag exists (workflow_dispatch) | |
| if: ${{ github.event_name == 'workflow_dispatch' }} | |
| run: | | |
| set -e | |
| echo "Validating that tag '${RELEASE_TAG}' exists in remote repository '${{ github.repository }}'..." | |
| if ! git ls-remote --exit-code --tags "https://github.com/${{ github.repository }}.git" "refs/tags/${RELEASE_TAG}" >/dev/null 2>&1; then | |
| echo "Error: Tag '${RELEASE_TAG}' does not exist in the remote repository 'https://github.com/${{ github.repository }}.git'." >&2 | |
| echo "Please push the tag before manually triggering this workflow with it." >&2 | |
| exit 1 | |
| fi |
Comment on lines
+44
to
+45
| - name: Build | ||
| run: npm run build |
There was a problem hiding this comment.
The workflow builds the package but doesn't run tests before publishing to npm. While releases typically follow CI validation, manual workflow_dispatch triggers could bypass testing. Consider adding a test step (npm test) before the build step to ensure code quality, especially since the repository has comprehensive test coverage.
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
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.
Closes #23
Summary:
fileswhitelist.Tests:
Rollback:
Summary by Sourcery
Add an automated npm publish workflow and restrict the published package contents.
Build:
fileswhitelist.CI: