chore(react-refresh-webpack-plugin): add missed changeset for peer range bump#2626
Conversation
…nge bump #2423 extended the `@lynx-js/react-webpack-plugin` peer range on `@lynx-js/react-refresh-webpack-plugin` to `^0.9.0`, but the changeset in that PR only bumped `@lynx-js/react`, `@lynx-js/react-webpack-plugin`, and `@lynx-js/react-rsbuild-plugin`. As a result the peer-range fix has been sitting on `main` without ever shipping a new `@lynx-js/react-refresh-webpack-plugin` version, so npm installs still resolve `0.3.5` with the old peer range, force a duplicate `@lynx-js/react-webpack-plugin@0.8.0` install, and pin `@lynx-js/template-webpack-plugin@0.10.9` at the top of node_modules alongside nested `0.11.0` copies. Add a patch-level changeset so the next release cuts a new `@lynx-js/react-refresh-webpack-plugin` carrying the fix.
🦋 Changeset detectedLatest commit: 9a311f1 The changes in this PR will be included in the next version bump. This PR includes changesets to release 3 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughA changeset file is added to document a patch release for ChangesPeer Dependency Range Update
Estimated Code Review Effort🎯 1 (Trivial) | ⏱️ ~2 minutes Possibly Related PRs
Suggested Labels
Suggested Reviewers
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ 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 |
46c5085 to
9a311f1
Compare
…set (#2627) ## Summary Add a CI check that catches the case where a PR modifies a package's `dependencies` or `peerDependencies` but the changesets in that PR don't bump the affected package. Without this guard, the dep change lands on `main` and sits there until someone makes another change that triggers a release — silently shipping broken peer ranges and tripping the kind of npm hoist conflict that surfaced as #2624. ## Concrete motivation #2423 widened the `@lynx-js/react-webpack-plugin` peer range on `@lynx-js/react-refresh-webpack-plugin`, but the changeset only bumped `@lynx-js/react`, `@lynx-js/react-webpack-plugin`, and `@lynx-js/react-rsbuild-plugin`. The peer-range fix sat unreleased; `npm install` consumers continued to pull the old `@lynx-js/react-refresh-webpack-plugin@0.3.5` with the narrow peer range, force a parallel `@lynx-js/react-webpack-plugin@0.8.0` install, pin `@lynx-js/template-webpack-plugin@0.10.9` at the top of `node_modules` next to nested `0.11.0` copies, and ultimately produce the build error tracked in #2624. The missed-changeset follow-up is #2626. Running this new check against the `#2423` state (locally, with `--since=$(git rev-parse 1f4f117^)`) reproduces the catch: ``` The following packages changed `dependencies` or `peerDependencies` but no changeset bumps them: - @lynx-js/react-refresh-webpack-plugin [peerDependencies] packages/webpack/react-refresh-webpack-plugin/package.json Add a changeset (e.g. `pnpm changeset add`) bumping each affected package so the dependency change actually ships in the next release. ``` Exit code is non-zero — CI would have blocked the PR until either a changeset was added or the dep change was reverted. ## What the check does For each `package.json` modified relative to the PR's base ref: - Skip `private: true` packages (not published, so no release-time impact). - Skip files newly added in the PR (initial release is a separate workflow). - Diff `dependencies` and `peerDependencies` against the base. `devDependencies` is intentionally ignored — those don't affect downstream consumers. - If the diff is non-empty and the changeset status report does **not** list the package, flag it. - Print all flagged packages with the field that changed, then exit non-zero. `isShallowEqual` is tolerant of key reordering and ignores anything outside the two examined fields, so changes that don't actually move the resolution surface (formatting, version-field re-sorts via `pnpm meta-updater`) don't trip the check. ## Integration Inserted in the existing `code-style-check` job, immediately after `Changeset Heading Check`. The script's own unit-test file is also exercised in the same step via `node --test`, so the helper logic gets regression coverage without spinning up a separate runner. ## Test plan - [x] `node --test .github/scripts/check-dep-changes-have-changeset.test.cjs` — 10 cases, all pass (key reorder tolerance, dev-deps-only skip, private-pkg skip, newly-added-pkg skip, multi-package flagging, etc.) - [x] Running the script against the `#2423` state reproduces the catch and exits non-zero - [x] Running against this branch itself returns "all good" (no dep changes here) - [ ] CI pass on this PR <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Chores** * Enhanced internal validation processes for dependency changes during the development workflow. --- **Note:** This release includes internal infrastructure improvements with no direct impact to end-user functionality. <!-- review_stack_entry_start --> [](https://app.coderabbit.ai/change-stack/lynx-family/lynx-stack/pull/2627) <!-- review_stack_entry_end --> <!-- end of auto-generated comment: release notes by coderabbit.ai -->
Summary
#2423 extended the
@lynx-js/react-webpack-pluginpeer range on@lynx-js/react-refresh-webpack-pluginto include^0.9.0:…but the changeset in that PR only bumped
@lynx-js/react,@lynx-js/react-webpack-plugin, and@lynx-js/react-rsbuild-plugin. Thereact-refresh-webpack-pluginchange has been sitting onmainwithout ever triggering a new release.Impact
The published
@lynx-js/react-refresh-webpack-plugin@0.3.5still ships the old (narrow) peer range, sonpm installconsumers continue to pull@lynx-js/react-webpack-plugin@0.8.0alongside the newer^0.9.0instance their direct deps demand. That parallel install in turn pins@lynx-js/template-webpack-plugin@0.10.9at the top ofnode_modulesand pushes0.11.0into nested copies under different parents — the exact precondition that drives theCannot destructure property 'buffer' of '(intermediate value)' as it is undefinedbuild error.(
pnpm installwas unaffected because its symlinked layout collapses references regardless.)Change
Single changeset file. No source code change is needed — the peer-range fix is already in place on
main; this entry just makes sure the next release cuts a new@lynx-js/react-refresh-webpack-plugincarrying it.Test plan
pnpm changeset statusnow lists@lynx-js/react-refresh-webpack-pluginunder "Packages to be bumped at patch"Summary by CodeRabbit