feat: display peerDependencies in deps page#123
Conversation
Add peerDependencies section alongside existing dependency types, following the same pattern as optionalDependencies. Adjusts layout from 3 columns to 4 columns to accommodate all dependency types. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
📝 WalkthroughWalkthroughThis pull request adds support for npm package peer dependencies across the codebase. It extends the type system to include an optional peerDependencies field in the NpmPackageVersion interface, updates the Deps component to extract and render peer dependencies alongside other dependency types, and adds corresponding test coverage. The layout is adjusted from three columns to four equal columns to accommodate the new peer dependencies section. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Poem
Pre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✨ Finishing touches
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 |
Summary of ChangesHello @fengmk2, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request significantly enhances the package dependency viewing experience by adding support for displaying Highlights
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
There was a problem hiding this comment.
Code Review
This pull request adds support for displaying peerDependencies on the dependencies page, which is a great feature enhancement. The implementation correctly follows the pattern of other dependency types. I've added a few suggestions to refactor some parts of the code to reduce duplication that has been introduced, which will improve the overall maintainability. The tests are also well-written and cover the new functionality, though they could also be refactored to be more concise. Overall, great work!
| describe('peerDependencies', () => { | ||
| it('should display peerDependencies section', () => { | ||
| const manifest = createMockManifest({ | ||
| peerDependencies: { | ||
| 'react': '^18.0.0', | ||
| }, | ||
| }); | ||
|
|
||
| render(<Deps manifest={manifest} version="1.0.0" />); | ||
|
|
||
| expect(screen.getByText('PeerDependencies (1)')).toBeInTheDocument(); | ||
| expect(screen.getByText('react')).toBeInTheDocument(); | ||
| expect(screen.getByText('^18.0.0')).toBeInTheDocument(); | ||
| }); | ||
|
|
||
| it('should display empty peerDependencies section when none exist', () => { | ||
| const manifest = createMockManifest({ | ||
| dependencies: { 'lodash': '^4.17.21' }, | ||
| }); | ||
|
|
||
| render(<Deps manifest={manifest} version="1.0.0" />); | ||
|
|
||
| expect(screen.getByText('PeerDependencies (0)')).toBeInTheDocument(); | ||
| }); | ||
|
|
||
| it('should display multiple peerDependencies', () => { | ||
| const manifest = createMockManifest({ | ||
| peerDependencies: { | ||
| 'react': '^18.0.0', | ||
| 'react-dom': '^18.0.0', | ||
| 'next': '^13.0.0', | ||
| }, | ||
| }); | ||
|
|
||
| render(<Deps manifest={manifest} version="1.0.0" />); | ||
|
|
||
| expect(screen.getByText('PeerDependencies (3)')).toBeInTheDocument(); | ||
| expect(screen.getByText('react')).toBeInTheDocument(); | ||
| expect(screen.getByText('react-dom')).toBeInTheDocument(); | ||
| expect(screen.getByText('next')).toBeInTheDocument(); | ||
| }); | ||
| }); |
There was a problem hiding this comment.
This new test suite for peerDependencies is great for coverage. However, it's almost identical to the existing suite for optionalDependencies. To avoid code duplication in tests, you could use describe.each from vitest to parameterize these tests. This would make the test file more concise and easier to maintain if other dependency types need similar tests in the future.
Here's an example of how you could combine the tests for optionalDependencies and peerDependencies:
describe.each([
{ depType: 'optionalDependencies', title: 'OptionalDependencies', pkgs: { 'fsevents': '^2.3.0', 'chokidar': '^3.5.0', 'esbuild': '^0.19.0' } },
{ depType: 'peerDependencies', title: 'PeerDependencies', pkgs: { 'react': '^18.0.0', 'react-dom': '^18.0.0', 'next': '^13.0.0' } },
])('$title', ({ depType, title, pkgs }) => {
it(`should display ${depType} section`, () => {
const firstPkg = Object.keys(pkgs)[0];
const manifest = createMockManifest({
[depType]: { [firstPkg]: pkgs[firstPkg] },
});
render(<Deps manifest={manifest} version=\"1.0.0\" />);
expect(screen.getByText(`${title} (1)`)).toBeInTheDocument();
expect(screen.getByText(firstPkg)).toBeInTheDocument();
expect(screen.getByText(pkgs[firstPkg])).toBeInTheDocument();
});
it(`should display empty ${depType} section when none exist`, () => {
const manifest = createMockManifest({
dependencies: { 'lodash': '^4.17.21' },
});
render(<Deps manifest={manifest} version=\"1.0.0\" />);
expect(screen.getByText(`${title} (0)`)).toBeInTheDocument();
});
it(`should display multiple ${depType}`, () => {
const manifest = createMockManifest({
[depType]: pkgs,
});
render(<Deps manifest={manifest} version=\"1.0.0\" />);
expect(screen.getByText(`${title} (3)`)).toBeInTheDocument();
for (const pkgName of Object.keys(pkgs)) {
expect(screen.getByText(pkgName)).toBeInTheDocument();
}
});
});Since this would involve refactoring existing tests, you might consider doing it in a follow-up PR.
| it('should create correct links for peerDependencies', () => { | ||
| const manifest = createMockManifest({ | ||
| peerDependencies: { | ||
| 'react': '^18.0.0', | ||
| }, | ||
| }); | ||
|
|
||
| render(<Deps manifest={manifest} version="1.0.0" />); | ||
|
|
||
| const link = screen.getByRole('link', { name: 'react' }); | ||
| expect(link).toHaveAttribute('href', '/package/react?version=%5E18.0.0'); | ||
| }); |
There was a problem hiding this comment.
This test is a good addition. Similar to my other comment, this test is very similar to the one for optionalDependencies just above it. You could use it.each to combine them and reduce duplication.
Example:
it.each([
{ depType: 'optionalDependencies', pkg: 'fsevents', version: '^2.3.0' },
{ depType: 'peerDependencies', pkg: 'react', version: '^18.0.0' },
])('should create correct links for $depType', ({ depType, pkg, version }) => {
const manifest = createMockManifest({
[depType]: { [pkg]: version },
});
render(<Deps manifest={manifest} version=\"1.0.0\" />);
const link = screen.getByRole('link', { name: pkg });
expect(link).toHaveAttribute('href', `/package/${pkg}?version=${encodeURIComponent(version)}`);
});This would make the tests more maintainable.
There was a problem hiding this comment.
Pull request overview
This PR adds support for displaying peerDependencies on the dependencies page, expanding the page from 3 to 4 dependency type sections. The implementation follows the same pattern established by the optionalDependencies feature added in PR #119.
Key Changes:
- Added peerDependencies type definition to the NpmPackageVersion interface
- Implemented peerDependencies data extraction and display in the Deps component
- Adjusted grid layout from 3 columns (span={8}) to 4 columns (span={6}) to accommodate all dependency types
- Added comprehensive test coverage for peerDependencies following the existing test patterns
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
src/hooks/useManifest.ts |
Added optional peerDependencies field to the NpmPackageVersion interface |
src/slugs/deps/index.tsx |
Implemented peerDependencies extraction, processing, and rendering; updated grid layout from 3 to 4 columns |
src/slugs/deps/index.test.tsx |
Added comprehensive test suite for peerDependencies including display tests, empty state tests, multiple dependencies tests, and link generation tests; updated existing tests to accommodate the fourth dependency type |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
src/slugs/deps/index.tsx (1)
62-109: Four-column layout works correctly, consider responsive breakpoints.The implementation correctly renders all four dependency types with equal-width columns (span={6}). The layout math is correct (4 × 6 = 24).
For improved UX on smaller screens, consider adding responsive breakpoints to stack or adjust column widths:
💡 Optional: Add responsive column sizing
- <Col span={6}> + <Col xs={24} sm={12} md={12} lg={6}> <Card title={`Dependencies (${dependencies.length})`}>Apply similar responsive props to all four
<Col>components. This would:
- Stack to 1 column on extra-small screens (xs: mobile)
- Show 2 columns on small/medium screens (sm/md: tablets)
- Show 4 columns on large screens (lg: desktop)
📜 Review details
Configuration used: defaults
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
src/hooks/useManifest.tssrc/slugs/deps/index.test.tsxsrc/slugs/deps/index.tsx
🧰 Additional context used
🧬 Code graph analysis (2)
src/slugs/deps/index.test.tsx (1)
src/slugs/deps/index.tsx (1)
Deps(32-110)
src/slugs/deps/index.tsx (1)
src/components/SizeContainer.tsx (1)
SizeContainer(11-32)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
- GitHub Check: Node.js / Test (ubuntu-latest, 22)
- GitHub Check: Node.js / Test (ubuntu-latest, 24)
- GitHub Check: Agent
🔇 Additional comments (4)
src/hooks/useManifest.ts (1)
30-30: LGTM! Type definition is correct and consistent.The addition of the optional
peerDependenciesfield follows the same pattern asoptionalDependenciesand correctly represents npm's peerDependencies as a mapping of package names to version ranges.src/slugs/deps/index.test.tsx (2)
92-133: Excellent test coverage for peerDependencies.The test suite comprehensively covers all scenarios: single dependency, empty state, multiple dependencies, and proper link generation. The tests follow the established pattern from optionalDependencies testing.
136-174: Integration tests properly updated for 4 dependency types.The tests correctly verify that all four dependency categories (Dependencies, DevDependencies, OptionalDependencies, PeerDependencies) are displayed together and handle missing version data gracefully.
src/slugs/deps/index.tsx (1)
33-60: LGTM! Data extraction logic is correct and consistent.The peerDependencies extraction follows the established pattern: defaults to an empty object when missing, maps entries to the standard
{ package, spec }format, and is properly memoized along with the other dependency types.

Summary
Test plan
🤖 Generated with Claude Code
Summary by CodeRabbit
New Features
Tests
✏️ Tip: You can customize this high-level summary in your review settings.