chore(deps): group @tiptap/* updates so peer-dep-coupled bumps land together#219
Conversation
…ogether PRs #211 and #213 sat open with failing CI because Dependabot raises one PR per package and tiptap's internal peer-dep structure forces lockstep version bumps: npm ERESOLVE could not resolve While resolving: @tiptap/react@3.26.0 Found: @tiptap/core@3.26.1 peer @tiptap/core@"3.26.0" from @tiptap/react@3.26.0 @tiptap/pm@3.26.1 and @tiptap/starter-kit@3.26.1 individually pull in @tiptap/core@3.26.1, which conflicts with @tiptap/react@3.26.0's peer requirement on core@3.26.0 exact. Bumped together they install cleanly. Adds a `tiptap` group matching `@tiptap/*` so future minor/patch bumps arrive as a single bundled PR that npm install accepts the first time. Doesn't fix the current open #211/#213 (their existing PRs need closing or Dependabot will recreate the group on next weekly run, leaving the old ones to be closed manually). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
Warning Review limit reached
More reviews will be available in 26 minutes and 11 seconds. Learn how PR review limits work. Your organization has used up its prepaid credits, and credit purchases are no longer available. Enable the review add-on in the billing tab to keep reviews running — you're only billed for reviews past your plan's rate limits ($0.25/file). ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans include higher PR review limits than trial, open-source, and free plans. In all cases, reviews become available again over time. During sustained high-volume PR review activity, CodeRabbit may temporarily slow when the next review becomes available. Please see our Fair Usage Limits Policy for further information. ✨ 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 |
Up to standards ✅🟢 Issues
|
Summary
Adds a
groups:block to the npm update config in.github/dependabot.ymlmatching@tiptap/*, so future tiptap minor/patch bumps arrive as a single bundled PR instead of one-per-package.Why
PRs #211 (
@tiptap/starter-kit3.26.0 → 3.26.1) and #213 (@tiptap/pm3.26.0 → 3.26.1) sat open with failing CI because tiptap's internal peer-dep structure forces lockstep version bumps. The actualnpm installerror:@tiptap/pm@3.26.1and@tiptap/starter-kit@3.26.1individually pull in@tiptap/core@3.26.1, but@tiptap/react@3.26.0(in the root project) has a peer requirement on@tiptap/core@3.26.0exact. Bumped together they install cleanly. Dependabot's default single-PR-per-package shape makes this fail every minor.What changes
Next weekly Dependabot run will detect the new group config and produce a single bundled PR for any tiptap updates pending.
Doesn't fix
shivammathur/setup-php2.37.2 (PR chore(deps): Bump shivammathur/setup-php from 2.37.1 to 2.37.2 #210) — already merged manually as part of this cleanup.Why only
@tiptap/*(not also@types/*,eslint*, etc.)Keeping the change minimal to the concrete failure that motivated it. Other co-coupled families can be added in follow-ups as they bite — premature grouping risks bundling unrelated updates and making rollback harder.
Test plan
groups:schema at https://docs.github.com/en/code-security/dependabot/working-with-dependabot/dependabot-options-reference#groups)🤖 Generated with Claude Code