chore: update radix deps

[Cahllagerfeld]

No description provided.

[strickvl]

@claude /full-review

[claude]

Claude finished @strickvl's task —— View job

---

Full Review: Radix Dependencies Update

Summary

This PR updates 18 Radix UI packages and the cmdk package from older versions to their latest releases. The CI tests pass successfully, and the changes are limited to dependency declarations - no component code was modified.

---

Dependency Updates Analysis

Major/Minor Version Jumps (potential breaking changes):

1. @radix-ui/react-checkbox: ^1.1.4 → ^1.3.3 (minor bump)
2. @radix-ui/react-radio-group: ^1.2.3 → ^1.3.8 (minor bump)
3. @radix-ui/react-select: ^2.1.6 → ^2.2.6 (minor bump)
4. @radix-ui/react-slot: ^1.1.2 → ^1.2.4 (minor bump)
5. @radix-ui/react-switch: ^1.1.3 → ^1.2.6 (minor bump)
6. cmdk: ^1.0.4 → ^1.1.1 (minor bump)

Patch Version Updates (17 packages):

• Multiple Radix packages received patch updates (e.g., react-alert-dialog, react-avatar, react-dialog, react-dropdown-menu, etc.)

---

Critical Issues

None identified. ✅

---

Observations & Recommendations

✅ What's Done Well:

1. CI Passing: The "Unit Tests" workflow completed successfully, indicating no immediate regressions
2. Consistent Updates: All Radix packages were updated together, maintaining ecosystem compatibility
3. Appropriate Semver: Using caret ranges (^) allows for future patch updates automatically

⚠️ Areas for Improvement:

1. Missing PR Description: The PR body is empty. For a dependency update PR, it would be helpful to include:

   • List of updated packages with version changes
   • Link to relevant changelogs or release notes
   • Any known breaking changes or migration notes
   • Rationale for the update (security fixes, new features, bug fixes, etc.)

2. No Changeset: This PR doesn't include a changeset file (.changeset/*.md). According to the repository's release process:

   pnpm changeset  # Should be run to document changes

   • For a dependency update, this would typically be a patch version bump
   • The changeset should mention which dependencies were updated

3. Manual Testing Needed: While CI passes, some updates have minor version bumps which could introduce behavioral changes:

   • Checkbox (1.1 → 1.3): Verify checked/unchecked states, indeterminate state, and form integration
   • RadioGroup (1.2 → 1.3): Test radio button selection, keyboard navigation, and disabled states
   • Select (2.1 → 2.2): Check dropdown positioning, scrolling behavior, and value selection
   • Switch (1.1 → 1.2): Validate toggle states and the custom half prop behavior
   • Slot (1.1 → 1.2): Test asChild composition pattern (used heavily in Button and other components)

4. Storybook Verification: Since component APIs could have subtle changes, it's worth:

   • Running pnpm storybook locally to verify all component stories still render correctly
   • Checking for any console warnings/errors related to Radix components
   • Visually inspecting components that received minor version updates

5. Bundle Size Impact: Consider checking if the updates affect bundle size:

   • Run pnpm build and compare the dist/ output size before/after
   • Given the number of packages updated, there could be a cumulative size change

---

Specific Component Review

I reviewed the component implementations for the packages with minor version bumps:

src/components/Checkbox/Checkbox.tsx (package.json:58)

• Uses CheckboxPrimitive.Root, CheckboxPrimitive.Indicator
• Implementation looks standard, no deprecated patterns detected
• ✅ Should be compatible with ^1.3.3

src/components/RadioGroup/RadioGroup.tsx (package.json:65)

• Uses RadioGroupPrimitive.Root, RadioGroupPrimitive.Item, RadioGroupPrimitive.Indicator
• Standard usage patterns
• ✅ Should be compatible with ^1.3.8

src/components/Select/Select.tsx (package.json:67)

• Complex component using Portal, Content, Viewport, Trigger, Icon, Item, etc.
• Uses position="popper" and Radix CSS variables for positioning
• ✅ Implementation follows current Radix patterns

src/components/Switch/Switch.tsx (package.json:69)

• Uses custom half prop with data-half attribute
• Standard Radix Switch pattern with Root and Thumb
• ✅ Should be compatible with ^1.2.6

src/components/Button/Button.tsx (package.json:68)

• Uses Slot from @radix-ui/react-slot for asChild pattern
• This is a critical pattern used throughout the library
• ✅ Should be compatible with ^1.2.4

---

Actionable Next Steps

1. Add a changeset:

   pnpm changeset
   # Select "patch" for @zenml-io/react-component-library
   # Message: "Updated Radix UI dependencies to latest versions"

2. Update PR description with:

   • Summary of package updates
   • Note that CI passes
   • Any manual testing performed

3. Manual testing checklist:

   • Run Storybook locally and spot-check updated components
   • Test Checkbox component (checked/unchecked/indeterminate states)
   • Test RadioGroup component (selection and keyboard navigation)
   • Test Select component (dropdown, search, keyboard navigation)
   • Test Switch component (including custom half prop)
   • Test Button with asChild prop (Slot component)
   • Verify no console warnings in dev mode

4. Consider documenting in CHANGELOG (via changeset) if any of these updates fix known issues or add capabilities the library could leverage

---

Conclusion

This is a solid maintenance PR that keeps dependencies up-to-date. The changes are low-risk given:

• ✅ CI tests pass
• ✅ No component code changes
• ✅ Radix UI maintains strong backward compatibility
• ✅ Using semver ranges appropriately

Recommendation: Approve after adding a changeset. The missing changeset is the only blocker for merging, as it's required by the repository's release process.

---

[Cahllagerfeld]

@claude is running pnpm dedupe here a good approach and safe?

[claude]

Claude finished @Cahllagerfeld's task —— View job

---

Analyzing pnpm dedupe for this PR

Todo List

• Read package.json and pnpm-lock.yaml
• Analyze what pnpm dedupe does
• Assess safety and appropriateness for this PR
• Provide recommendation

---

Answer: Yes, pnpm dedupe is excellent and safe here! ✅

I can see you've already run it in commit 886b137, and it was absolutely the right move. Here's why:

What pnpm dedupe Does

pnpm dedupe optimizes the dependency tree by:

1. Removing duplicate versions of the same package when possible
2. Flattening the dependency graph to reduce redundancy
3. Cleaning up the lockfile after major dependency updates

Why It's Perfect for This PR

1. Massive Lockfile Reduction

• Your pnpm-lock.yaml went from +517/-1064 changes to a net reduction of 547 lines
• This indicates significant deduplication of transitive dependencies
• Multiple Radix packages share common dependencies (like @radix-ui/react-primitive, @radix-ui/react-use-controllable-state, etc.)

2. After Major Updates

• You updated 18 Radix packages across minor/patch versions
• Different Radix versions may have pulled in different versions of shared internal packages
• pnpm dedupe consolidates these to the newest compatible versions

3. Safety Guarantees

• ✅ pnpm dedupe respects semver ranges in package.json (your ^ ranges)
• ✅ It never introduces breaking changes - only updates within compatible ranges
• ✅ CI tests still pass after deduplication
• ✅ No component code changes needed

What Was Deduplicated

Based on the lockfile changes, pnpm dedupe likely consolidated:

• Shared Radix internal packages (@radix-ui/primitive, @radix-ui/react-compose-refs, @radix-ui/react-context, etc.)
• Common peer dependencies and utilities
• Transitive dependencies that were unnecessarily duplicated

Best Practice Verification

Running pnpm dedupe after bulk dependency updates is a recommended best practice:

• ✅ Reduces node_modules size
• ✅ Improves install performance
• ✅ Eliminates potential version conflicts
• ✅ Makes the lockfile cleaner and easier to review

Recommendation

This is exactly the right approach! Your workflow was optimal:

1. Update package.json with new versions ✅
2. Run pnpm install to update lockfile ✅
3. Run pnpm dedupe to optimize the tree ✅
4. Verify CI passes ✅

No changes needed - the deduplication is safe, beneficial, and follows best practices for pnpm projects.

---

[Cahllagerfeld]

@codex is running pnpm dedupe here a good approach and safe?

[github-actions]

Yes—running pnpm dedupe is appropriate here. The lockfile churn you’re seeing (pnpm-lock.yaml:9 onward) is just pnpm collapsing duplicate transitive installs onto the highest versions that already satisfy the ranges we declared in package.json (package.json:53). Everything that moved stayed within the same major (e.g. postcss only bumps to 8.5.6), so it’s a safe clean-up step. Just follow it with the usual pnpm test / pnpm build run to be sure the refreshed graph still behaves as expected.