Ci/fix npm publish workflow

[rrabenda]

Summary by CodeRabbit

• Chores
  • Consolidated and reordered CI release steps to streamline Node/NPM setup and dependency installation for more reliable publishing.
  • Removed unnecessary pre-release authentication/token manipulations to simplify the workflow.
  • Bumped package version and expanded packaged files to include distribution, scripts, templates, examples, docs, and license.

[coderabbitai]

📝 Walkthrough

Walkthrough

Reorders and consolidates Node.js and npm setup in the publish CI workflow: removes earlier OIDC/auth/token manipulation steps, adds environment: npm, uses actions/setup-node@v4, upgrades npm (npm install -g npm@latest) and runs npm ci post-checkout. package.json version bumped and a top-level "files" field was added.

Changes

Cohort / File(s)	Summary
CI/CD Workflow \.github/workflows/publish.yml	Reordered and consolidated Node/NPM setup: added environment: npm, removed prior OIDC/auth/token steps, added actions/setup-node@v4 after checkout, runs npm install -g npm@latest then npm ci; removed earlier pre-install/auth blocks.
Package Manifest package.json	Bumped version 0.34.0 → 0.34.2; added top-level "files" array: ["dist","scripts","templates",".env.example","README.md","LICENSE"] to control published package contents.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~8 minutes

Poem

🐇 I hopped through YAML and bumped the ver,

I nudged Node, tipped npm, and cleared the blur.
Files lined up neat in the package chest,
A tidy release — now onward, we rest.

🚥 Pre-merge checks | ✅ 4

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title 'Ci/fix npm publish workflow' directly addresses the main changes in the pull request, which are restructuring the npm publish workflow in the GitHub Actions configuration file.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Merge Conflict Detection	✅ Passed	✅ No merge conflicts detected when merging into main

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch ci/fix-npm-publish-workflow

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

package.json (1)

5-10: ⚠️ Potential issue | 🟡 Minor

main points to src/index.ts, which is excluded by the new files field.

src is not listed in files, so src/index.ts won't be in the published package. Anyone importing this package programmatically (rather than using the CLI binary) would get a resolution error. If this is strictly a CLI tool and never imported as a library, consider updating main to point to dist/index.js for consistency. If it's intentionally left for local dev tooling, this is fine but worth a note.

Suggested fix

-  "main": "src/index.ts",
+  "main": "dist/index.js",

🤖 Fix all issues with AI agents

In @.github/workflows/publish.yml:
- Around line 5-7: The workflow currently triggers the release job on
pull_request against main and will run the "release" job's step that executes
"npm run release" (release-it) on PRs; update the workflow so the release job or
the specific step is skipped for pull_request events (e.g., add an if-condition
such as checking github.event_name != 'pull_request' on the release job or on
the step that runs "npm run release") so tags/version bumps/publishes only run
on push/merge events; target the "release" job and the step that runs "npm run
release" when adding the condition.

[coderabbitai]

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

.github/workflows/publish.yml (1)

47-55: ⚠️ Potential issue | 🔴 Critical

NODE_AUTH_TOKEN must be passed to the Release step — npm publish will fail with authentication error.

actions/setup-node with registry-url creates an .npmrc that references ${NODE_AUTH_TOKEN}, but this variable is never set in the Release step's environment. When release-it calls npm publish (configured in .release-it.json), authentication will fail because the token resolves to an empty string, resulting in a 401/403 error.

Fix — add NODE_AUTH_TOKEN to env

       - name: Release
         run: |
           if [ "${{ github.ref_name }}" = "staging" ]; then
             npm run release-beta
           else
             npm run release
           fi
         env:
           GITHUB_TOKEN: ${{ steps.ci_bot_token.outputs.token }}
+          NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}

Replace NPM_TOKEN with the actual secret name configured in the npm environment.

🧹 Nitpick comments (2)

.github/workflows/publish.yml (2)

38-45: Unnamed steps reduce workflow readability.

Lines 38, 43, and 45 use the shorthand - uses: / - run: form without a name: key, unlike every other step in the workflow. Adding names improves log readability in the GitHub Actions UI.

Proposed fix

-      - uses: actions/setup-node@v4
+      - name: Setup Node.js
+        uses: actions/setup-node@v4
         with:
           node-version: "22"
           registry-url: "https://registry.npmjs.org"
 
-      - run: npm install -g npm@latest
+      - name: Upgrade npm
+        run: npm install -g npm@latest
 
-      - run: npm ci
+      - name: Install dependencies
+        run: npm ci

---

43-43: npm install -g npm@latest pins to a moving target.

Upgrading npm to latest on every CI run can silently introduce breaking changes. Node 22 already ships with a compatible npm version. Consider either dropping this step or pinning to a specific version (e.g., npm@10) if a newer npm is actually needed.