Conversation
Prerelease tags (e.g. v1.0.0-beta.1) now publish with --tag beta instead of the implicit latest, so a beta version never becomes the default install for existing consumers. Also add workflow_dispatch so a given tag can be re-published on demand without needing a new push event.
ci(PP-3449): publish prereleases under npm beta dist-tag
…xtures
Bump root, test-nextjs, test-nextjs-cjs, and test-commonjs devDependencies/
dependencies to latest, including major bumps (http-proxy-middleware v4,
ejs v6, @types/node v26, Next.js/React/Tailwind patch releases).
Intentionally NOT bumped:
- undici stays on latest 7.x (not v8): the root/test-nextjs override forces
a single undici resolution repo-wide, and jsdom pins ^7.25.0 and reaches
into undici's internal file layout (require('undici/lib/handler/
wrap-handler.js')), which v8 restructured. Bumping breaks jsdom at runtime.
- eslint stays on latest 9.x (not v10) in test-nextjs/test-nextjs-cjs:
eslint-config-next@16.2.10 only supports eslint ^3-^9 as a peer; v10
installs only via forced ERESOLVE overrides.
- jquery/@types/jquery stay on latest 3.x (not v4) in test-commonjs: the
fixture mirrors a real Portal Page template, and the MI backend that
serves /js/jquery/jquery-latest.min.js in production still serves v3.
Verified: npm run audit:all (0 vulnerabilities across all 4 packages),
tsc --noEmit, eslint, 185 unit + 39 integration tests, and production
builds all green for root, test-nextjs, test-nextjs-cjs, and test-commonjs.
chore(PP-3449): update dependencies to latest
📝 WalkthroughWalkthroughThe release workflow now supports manual dispatch and publishes with a computed npm dist-tag based on the version tag format. Root and test fixture package manifests also have updated dependency, devDependency, and override version ranges, plus a package version bump and changelog entry. ChangesRelease Workflow Dist-Tag
Dependency Version Bumps
Estimated code review effort: 2 (Simple) | ~10 minutes Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (2)
.github/workflows/release.yml (1)
67-67: 🔒 Security & Privacy | 🔵 Trivial | 💤 Low valueHarden the
run:interpolation flagged by zizmor.
steps.version.outputs.tagis constrained to the literalsbeta/latestset earlier in the same job, so actual injection risk here is minimal. Still, per GitHub's Actions hardening guidance, passing${{ }}expressions through an env var rather than interpolating directly into the shell script is the safer pattern and would silence this static-analysis finding.🔒 Proposed refactor
- name: Publish to npm - run: npm publish --access public --tag ${{ steps.version.outputs.tag }} + env: + NPM_TAG: ${{ steps.version.outputs.tag }} + run: npm publish --access public --tag "$NPM_TAG"🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/release.yml at line 67, The npm publish command is interpolating steps.version.outputs.tag directly in the run script, which triggers the zizmor hardening finding. Update the release job in the workflow to pass that value through an env var first, then reference the env var in the publish command; use the existing steps.version.outputs.tag output as the source and keep the npm publish step behavior unchanged.Source: Linters/SAST tools
tests/test-nextjs/package.json (1)
33-33: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low valueDuplicate
rollupentry acrossdependenciesanddevDependencies.
rollup: "^4.62.2"is declared in bothdependencies(Line 33) anddevDependencies(Line 54) with the identical version. Ifrollupis only needed for the build/dev toolchain, consider dropping it fromdependenciesto avoid an unnecessary redundant/confusing entry.♻️ Proposed cleanup (if rollup is dev-only)
"dependencies": { ... - "rollup": "^4.62.2", "sass": "^1.101.0",Also applies to: 41-58
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@tests/test-nextjs/package.json` at line 33, `rollup` is duplicated in both the dependencies and devDependencies sections of the package.json, so remove the redundant entry from dependencies if it is only used by the build/tooling flow. Keep the single source of truth in devDependencies and verify the package.json around the rollup entry and the dependencies/devDependencies blocks stays consistent.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/release.yml:
- Line 7: The release workflow can be manually dispatched from a non-tag ref,
which would make VERSION derive from a branch name instead of a release tag.
Update the workflow around workflow_dispatch and the version derivation in the
release job so it only proceeds when GITHUB_REF_NAME matches the expected v* tag
format, or otherwise exits early with a clear guard. Use the existing VERSION
assignment path and the release job steps to add the validation before any
build, bump, or publish actions run.
---
Nitpick comments:
In @.github/workflows/release.yml:
- Line 67: The npm publish command is interpolating steps.version.outputs.tag
directly in the run script, which triggers the zizmor hardening finding. Update
the release job in the workflow to pass that value through an env var first,
then reference the env var in the publish command; use the existing
steps.version.outputs.tag output as the source and keep the npm publish step
behavior unchanged.
In `@tests/test-nextjs/package.json`:
- Line 33: `rollup` is duplicated in both the dependencies and devDependencies
sections of the package.json, so remove the redundant entry from dependencies if
it is only used by the build/tooling flow. Keep the single source of truth in
devDependencies and verify the package.json around the rollup entry and the
dependencies/devDependencies blocks stays consistent.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 94087d2a-b134-4323-abee-db1743bfcbed
⛔ Files ignored due to path filters (4)
package-lock.jsonis excluded by!**/package-lock.jsontests/test-commonjs/package-lock.jsonis excluded by!**/package-lock.jsontests/test-nextjs-cjs/package-lock.jsonis excluded by!**/package-lock.jsontests/test-nextjs/package-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (5)
.github/workflows/release.ymlpackage.jsontests/test-commonjs/package.jsontests/test-nextjs-cjs/package.jsontests/test-nextjs/package.json
workflow_dispatch lets this workflow run against any ref (branch or tag). Without a check, dispatching against main/develop would derive VERSION from the branch name and proceed to build/bump/publish with a bogus version. Exit early unless GITHUB_REF_NAME matches a v* tag. Addresses CodeRabbit review comment on PR #186.
1 task
fix(PP-3449): guard release.yml against non-tag workflow_dispatch runs
# [0.20.0-beta.4](v0.20.0-beta.3...v0.20.0-beta.4) (2026-07-02) ### Bug Fixes * **PP-3449:** guard release.yml against non-tag workflow_dispatch runs ([a7f463f](a7f463f))
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@CHANGELOG.md`:
- Line 4: The changelog subsection heading is using the wrong markdown level,
skipping from the release title to H3 and causing inconsistent structure. Update
the heading in the changelog section from `### Bug Fixes` to `## Bug Fixes` so
the subsection matches the surrounding release format and markdownlint
expectations.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: e53ca605-8a5e-464f-a2ad-d3b4540878b1
⛔ Files ignored due to path filters (1)
package-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (3)
.github/workflows/release.ymlCHANGELOG.mdpackage.json
✅ Files skipped from review due to trivial changes (1)
- package.json
🚧 Files skipped from review as they are similar to previous changes (1)
- .github/workflows/release.yml
MaksymovVolodymyr
approved these changes
Jul 2, 2026
michailozdemir
approved these changes
Jul 2, 2026
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
4 participants
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.
chore(PP-3449): promote develop to main
Summary
Promotes
developtomain. Since the last promotion (#182), two follow-up changes landed ondevelop: a safer npm release flow for prerelease/beta versions, and a full dependency refresh across the root package and all three test fixtures.Key changes
v1.0.0-beta.1) now publish to npm under thebetadist-tag instead oflatest, so a beta build can never become the default install for existing consumers. Testers opt in explicitly vianpm install @metricinsights/pp-dev@beta. Final versions are unaffected. Also addsworkflow_dispatchtorelease.ymlso a given tag can be manually re-run later.test-nextjs+test-nextjs-cjs+test-commonjsto latest, including major bumps (http-proxy-middleware3→4,ejs5→6,@types/node25→26) plus routine minor/patch bumps (next,react,vite,vitest,rollup,sass,prettier,axios,sharp,tailwindcss, etc.).undicistays on7.x(v8 breaksjsdom's internal file resolution),eslintstays on9.xin the Next.js fixtures (eslint-config-nextdoesn't support10.xyet), andjquery/@types/jquerystay on3.xintest-commonjs(matches what the real MI backend still serves in production).npm run audit:all(0 vulnerabilities across all 4 packages),tsc --noEmit,eslint, 185 unit + 39 integration tests, and production builds for root and all three fixtures.Included commits
Testing
npm run audit:all— 0 vulnerabilities (root + 3 fixtures)npx tsc --noEmit— cleannpm run lint— cleannpm run test:unit— 185 passednpm run test:integration— 39 passednpm run build— succeeds for root and all 3 fixturesMerge Request:
origin/develop→origin/mainSummary by CodeRabbit
betafor prereleases,latestfor stable releases).