we can now install from shadcn #43
Conversation
WalkthroughThe changes update the GitHub Actions workflow by incrementing the Docker image tag, adjust the UI in the marketing page to reflect a higher star count, and enhance component documentation. A new installation component with tabbed CLI and manual instructions has been added along with styling adjustments. Configuration files now include dependency fields and updated file paths. Additionally, new registry JSON entries and a registry schema have been added, and export modifications have been made in various UI modules. A new build script and dependency were also introduced in the package configuration. Changes
Sequence Diagram(s)sequenceDiagram
participant U as User
participant R as MDX Renderer
participant CI as ComponentInstall
participant CLI as ComponentInstall.Cli
participant MAN as ComponentInstall.Manual
U->>R: Render documentation page
R->>CI: Display installation section
CI->>U: Show tab options (CLI & Manual)
U->>CI: Select CLI tab
CI->>CLI: Render CLI installation command
U->>CI: Select Manual tab
CI->>MAN: Render manual installation instructions
Poem
✨ 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. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
ariflogs
changed the title
ariflogs
changed the title
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🔭 Outside diff range comments (1)
config/components.ts (1)
273-277:⚠️ Potential issueFix incorrect name for tab-style-default
The tab-style-default example has an incorrect name ("typography-p"). This should be updated to "tab-style-default" for consistency.
Apply this change:
"tab-style-default": { - name: "typography-p", + name: "tab-style-default", filePath: "preview/components/tab-style-default.tsx", preview: lazy(() => import("@/preview/components/tab-style-default")), },
🧹 Nitpick comments (16)
public/r/textarea.json (2)
6-6: Clarify Component DescriptionThe description on line 6 currently reads:
"This pretty input makes your users want to type lots of stuff! ⌨️ ⌨"
Since this component renders a<textarea>(and not an<input>), consider revising the description for clarity and consistency. For example, updating it to reference “textarea” will help avoid potential confusion.
10-10: Review UnusedtypeProp in Component SignatureWithin the
"content"string, theTextareacomponent destructures atypeprop with a default value of"text". However, the<textarea>HTML element does not support atypeattribute, and this prop is not used in the rendered output. If this prop is not intended for future extensions or API consistency, it might be best to remove it to avoid confusion.content/docs/components/card.mdx (1)
11-12: Empty lines should be removed.There are two consecutive empty lines (11-12) before the "Installation" section heading which appears to be unintentional and inconsistent with the formatting in other component files.
7 <ComponentShowcase name="card-style-default" /> 8 <br /> 9 <br /> 10 - - 13 ## Installationpackage.json (1)
35-35:❓ Verification inconclusive
Consider using a stable version of shadcn package
The current implementation uses a canary (pre-release) version of shadcn (2.4.0-canary.10). While this may be required for the registry functionality, canary versions can introduce instability. Consider upgrading to a stable version once available or document why this specific version is needed.
🌐 Web query:
What is the latest stable version of the shadcn package?💡 Result:
The latest stable version of the shadcn CLI package is 2.3.0, as indicated by the
package.jsonfile in its GitHub repository[3]. This version includes framework detection, monorepo support, and enhanced component management features like dependency auto-installation and registry schema customization[1][3][4].For the deprecated shadcn-ui package (now replaced by shadcn), the last stable release was 0.9.4 on npm[2]. The new CLI-focused shadcn package has since adopted semantic versioning, with current development focused on the 2.4.0-canary.12 pre-release[7].
Key differences between versions:
Version Type Package Name Features 2.3.0 (Stable) shadcn Next.js/Remix/Vite support, Tailwind auto-config, component registry schema[1][4] 0.9.4 (Legacy) shadcn-ui Original component library implementation[2] Developers should migrate to the shadcn CLI package for new projects, as it supersedes the older shadcn-ui implementation[2][7].
Citations:
- 1: https://ui.shadcn.com/docs/changelog
- 2: https://www.npmjs.com/package/shadcn-ui?activeTab=versions
- 3: https://github.com/shadcn-ui/ui/blob/main/packages/shadcn/package.json
- 4: https://ui.shadcn.com/docs/cli
- 5: https://github.com/Bekacru/schadcn-ui/blob/main/package.json
- 6: https://www.youtube.com/watch?v=kol1ogbjxqo
- 7: https://www.npmjs.com/package/shadcn?activeTab=versions
- 8: https://www.shadcndesign.com/docs/updates
- 9: https://en.wikipedia.org/wiki/CURL
- 10: https://ui.shadcn.com/docs/react-19
Subject: Please review the shadcn version choice
The package.json currently specifies a pre-release version of shadcn ("2.4.0-canary.10"). Note that the latest stable release of the shadcn CLI package is 2.3.0. Canary versions might offer new registry functionality but can introduce instability. If you intentionally require the canary version for its experimental features, please document the reasoning. Otherwise, consider switching to the stable version.
content/docs/components/select.mdx (1)
22-23: Empty content in the Manual tab needs to be filled.There's a blank line in the Manual installation section that might need content or could be removed for better presentation.
<ComponentInstall.Manual> -public/r/switch.json (1)
6-6: Fix grammatical error in component description.There's a grammatical error in the description text that should be corrected.
- "description": "Let users to turn on or off your marketing emails or notifications.", + "description": "Let users turn on or off your marketing emails or notifications.",public/r/label.json (1)
10-10: Consider enhancing the label with accessible default styling.The current implementation of Label uses minimal styling. Consider enhancing the default styling to improve readability and accessibility.
- "content": "import * as React from \"react\";\nimport * as LabelPrimitive from \"@radix-ui/react-label\";\nimport { cva } from \"class-variance-authority\";\n\nimport { cn } from \"@/lib/utils\";\n\nconst labelVariants = cva(\n \"leading-none peer-disabled:cursor-not-allowed peer-disabled:opacity-70\"\n);\n\nconst Label = ({\n className,\n ...props\n}: React.ComponentProps<typeof LabelPrimitive.Root>) => (\n <LabelPrimitive.Root className={cn(labelVariants(), className)} {...props} />\n);\n\nexport { Label };\n", + "content": "import * as React from \"react\";\nimport * as LabelPrimitive from \"@radix-ui/react-label\";\nimport { cva } from \"class-variance-authority\";\n\nimport { cn } from \"@/lib/utils\";\n\nconst labelVariants = cva(\n \"text-sm font-medium leading-none peer-disabled:cursor-not-allowed peer-disabled:opacity-70\"\n);\n\nconst Label = ({\n className,\n ...props\n}: React.ComponentProps<typeof LabelPrimitive.Root>) => (\n <LabelPrimitive.Root className={cn(labelVariants(), className)} {...props} />\n);\n\nexport { Label };\n",content/docs/components/text.mdx (1)
38-53: Clear Manual Installation SectionThe manual installation section is properly delineated. The dependency installation command uses the
shcode block marker, which is appropriate given the context. Consider removing any extraneous whitespace inside<ComponentInstall.Manual>if consistency is desired.config/components.ts (1)
2-305: Consider adding dependencies for other componentsWhile you've added dependencies for the accordion component, several other components likely have external dependencies as well. For example:
- dialog appears to use RadixUI
- menu references @radix-ui/react-dropdown-menu in its documentation
Consider adding dependency information for all components to provide a consistent experience.
content/docs/components/dialog.mdx (1)
14-14: Fix typo in section headingThere's a typo in the section heading - "Instalation" should be "Installation".
-## Instalation +## Installationpublic/r/avatar.json (1)
8-11: Ensure all dependencies are properly documentedThe Avatar component relies on
@radix-ui/react-avatar, but this dependency isn't explicitly listed in the JSON file. Consider adding adependenciesfield to make installation smoother."description": "Default rounded avatar that can show your users profile picture. ✨", + "dependencies": ["@radix-ui/react-avatar"], "files": [public/r/accordion.json (2)
8-11: Ensure all dependencies are properly documentedThe Accordion component relies on
@radix-ui/react-accordionandlucide-reactfor the ChevronDown icon. Consider explicitly listing these dependencies in the JSON file for clarity."description": "This collapsible component let's your users read only the content they care about. 😌", + "dependencies": ["@radix-ui/react-accordion", "lucide-react"], "files": [
6-6: Fix apostrophe in description textThere's a grammatical error in the description - "let's" should be "lets" (without the apostrophe) since it's being used as a verb, not a contraction.
- "description": "This collapsible component let's your users read only the content they care about. 😌", + "description": "This collapsible component lets your users read only the content they care about. 😌",components/ComponentInstall.tsx (2)
1-3: Remove unused importsThe imports for
componentConfigandCodeare not used in this file and should be removed.-import { componentConfig } from "@/config"; import { Tab, TabGroup, TabList, TabPanel, TabPanels } from "@headlessui/react"; -import { Code } from "lucide-react"; import { HTMLAttributes } from "react";
6-6: Update interface to match actual component propsThe
IComponentShowcaseinterface extendsHTMLAttributes<HTMLDivElement>but the component only uses thechildrenprop. Consider updating the interface to be more specific to the component's actual usage.-interface IComponentShowcase extends HTMLAttributes<HTMLDivElement> {} +interface IComponentInstallProps { + children: React.ReactNode; +}public/r/radio.json (1)
1-14: Nitpick: Clarify Radio Component Description
The registry entry is well structured and the embedded implementation (definingRadioGroupRootandRadioItem) leverages Radix UI effectively. However, the description "Sometimes you need to pick multiple options!" is slightly misleading because radio components traditionally allow a single choice. Consider revising it to reflect that users are meant to make a single selection (or update the implementation if multiple selections are intended). For example:- "description": "Sometimes you need to pick multiple options! That's where the Radio component comes into play.", + "description": "Choose one option from a set – that’s the traditional behavior of a radio component.",
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (41)
.github/workflows/deploy.yml(1 hunks)app/(marketing)/page.tsx(1 hunks)components/ComponentInstall.tsx(1 hunks)components/ComponentShowcase.tsx(1 hunks)components/MDX.tsx(2 hunks)config/components.ts(3 hunks)content/docs/components/accordion.mdx(2 hunks)content/docs/components/alert.mdx(2 hunks)content/docs/components/avatar.mdx(2 hunks)content/docs/components/badge.mdx(2 hunks)content/docs/components/button.mdx(2 hunks)content/docs/components/card.mdx(1 hunks)content/docs/components/checkbox.mdx(2 hunks)content/docs/components/dialog.mdx(2 hunks)content/docs/components/input.mdx(1 hunks)content/docs/components/menu.mdx(1 hunks)content/docs/components/radio.mdx(1 hunks)content/docs/components/select.mdx(2 hunks)content/docs/components/switch.mdx(2 hunks)content/docs/components/text.mdx(1 hunks)package.json(2 hunks)packages/ui/Form/index.tsx(1 hunks)packages/ui/index.ts(0 hunks)public/r/accordion.json(1 hunks)public/r/alert.json(1 hunks)public/r/avatar.json(1 hunks)public/r/badge.json(1 hunks)public/r/button.json(1 hunks)public/r/card.json(1 hunks)public/r/checkbox.json(1 hunks)public/r/dialog.json(1 hunks)public/r/input.json(1 hunks)public/r/label.json(1 hunks)public/r/menu.json(1 hunks)public/r/radio.json(1 hunks)public/r/select.json(1 hunks)public/r/switch.json(1 hunks)public/r/tab.json(1 hunks)public/r/text.json(1 hunks)public/r/textarea.json(1 hunks)registry.json(1 hunks)
💤 Files with no reviewable changes (1)
- packages/ui/index.ts
✅ Files skipped from review due to trivial changes (3)
- app/(marketing)/page.tsx
- .github/workflows/deploy.yml
- registry.json
🔇 Additional comments (55)
public/r/textarea.json (2)
1-7: JSON Metadata and Schema ValidationThe file’s metadata is well-formed and correctly references the registry schema. All key properties (
$schema,name,type,title, anddescription) appear correctly defined and consistent with the registry format.
8-13: Component File Registration and Content FormattingThe registration of the component file is correctly structured. The
"path"points to"packages/ui/Form/Textarea.tsx", and the"content"field contains a valid, escaped TypeScript code snippet for theTextareacomponent. The use of newlines and escape sequences is correctly handled via the JSON string formatting.content/docs/components/checkbox.mdx (2)
16-37: Well-structured installation component with both CLI and manual options.The addition of the
ComponentInstallcomponent with tabbed interface provides users with clear installation options. The CLI command correctly implements the new shadcn installation method mentioned in the PR objectives, while preserving the manual installation instructions for those who prefer that approach.
19-19: CLI installation path is correctly implemented.The command uses the expected format
npx shadcn@latest add "https://retroui.dev/r/checkbox.json"which aligns perfectly with the PR objective of enabling installation from the shadcn registry.packages/ui/Form/index.tsx (1)
6-7: Appropriate export additions for Form components.Adding exports for the Label and Input components from the Form directory makes these components available to consumers of the library, supporting the component registry system. This is a necessary change to ensure the components can be used when installed via shadcn.
content/docs/components/card.mdx (3)
14-27: Installation component implementation is consistent with other files.The
ComponentInstallcomponent with CLI and manual tabs has been implemented consistently with other component documentation files, providing a uniform experience across the documentation.
17-17: CLI installation path is correctly implemented.The command
npx shadcn@latest add "https://retroui.dev/r/card.json"correctly follows the expected format and points to the right component JSON in the registry.
20-25:❓ Verification inconclusive
Manual installation section is missing dependency installation instructions.
Unlike the checkbox component, the card component's manual installation section doesn't include a "1. Install dependencies" step. If the card component requires any dependencies, this section should be added for consistency with other component documentation.
🏁 Script executed:
#!/bin/bash # Check if the card component has any dependencies that should be listed # Search for any dependency imports in the card component file fd -e tsx -e ts "card" --exec grep -l "import.*from.*@" {} \; # Alternatively, check the registry JSON to see if dependencies are listed if [ -f "public/r/card.json" ]; then cat public/r/card.json | grep -A 10 "dependencies" fiLength of output: 313
Action Required: Update Manual Installation Instructions for Card Component Dependencies
While reviewing the manual installation section incontent/docs/components/card.mdx, it appears that the dependency installation step (present in the Checkbox component docs) is missing for the card component. Our initial checks recovered several card component TSX files that include import statements from external packages (e.g. from modules starting with “@”), yet the dependency configuration inpublic/r/card.jsondid not clearly list any dependencies.Please verify whether the Card component requires any external dependencies. If it does, add a “1. Install dependencies” step in the manual installation guide (similar to what’s done for the Checkbox component). If not, consider adding a note to clarify that no additional dependency installation is needed.
content/docs/components/switch.mdx (2)
16-37: Well-structured installation component consistent with other components.The implementation of the
ComponentInstallcomponent follows the same pattern as other component documentation files, maintaining a consistent user experience across the documentation.
19-19: CLI installation path is correctly implemented.The command
npx shadcn@latest add "https://retroui.dev/r/switch.json"follows the expected format and correctly points to the switch component JSON in the registry.content/docs/components/input.mdx (2)
12-25: New installation section enhances documentation usabilityThe addition of the
<ComponentInstall>component with tabbed interface provides a clear separation between CLI and manual installation methods, making it easier for users to choose their preferred approach. The CLI option leverages the new shadcn registry functionality.
15-15:✅ Verification successful
Verify that the registry URL path is correct and functional
Make sure that the registry URL
https://retroui.dev/r/input.jsonexists and contains the proper component configuration. The PR objectives mention enabling installation from the shadcn registry, so this is a critical path.
🏁 Script executed:
#!/bin/bash # Description: Verify that the input.json registry file exists and is valid # Check if the file exists in the public directory if [ -f "public/r/input.json" ]; then echo "✅ The file exists" cat "public/r/input.json" | jq '.' else echo "❌ The file doesn't exist at public/r/input.json" # Check if it exists in any other location fd "input.json" --type f fiLength of output: 1150
Validation Complete: Registry URL Verified as Functional
- Verified that the file at
public/r/input.jsonexists.- Confirmed the JSON structure matches the expected schema and component configuration.
The registry URL
https://retroui.dev/r/input.jsonis correct and functional as per the verification. No further changes are required.components/MDX.tsx (2)
94-94: ComponentInstall successfully added to MDX componentsAdding ComponentInstall to the components object enables its use in MDX files. This implementation properly supports the new installation UI for components.
11-12:✅ Verification successful
Verify TabGroup import usage
The TabGroup component is imported but not directly used in this file. If it's not used within the ComponentInstall component either, consider removing this unused import.
🏁 Script executed:
#!/bin/bash # Description: Check whether TabGroup is used in ComponentInstall.tsx # Look for the ComponentInstall component if [ -f "components/ComponentInstall.tsx" ]; then echo "✅ ComponentInstall.tsx exists" grep -n "TabGroup" "components/ComponentInstall.tsx" else echo "❌ ComponentInstall.tsx not found" # Try to find where ComponentInstall is defined fd "ComponentInstall" --type f --exec grep -l "TabGroup" {} \; fiLength of output: 284
TabGroup Import Usage Verified
The TabGroup component is actively used in
components/ComponentInstall.tsx(refer to lines 18 and 29), which confirms that its import incomponents/MDX.tsxis necessary. No changes are required.package.json (1)
10-10: New registry build script supports shadcn integrationThe "registry:build" script is well-implemented and matches the PR objective of enabling shadcn registry support. This script will be used to build registry components.
public/r/menu.json (3)
1-14: Well-structured registry component for menuThe menu.json registry file follows the correct schema and includes all necessary information for the component. The implementation included in this file is comprehensive and uses Radix UI's dropdown menu for accessibility.
9-10:✅ Verification successful
Ensure Menu component file path is correct
Verify that the file path "packages/ui/Menu/Menu.tsx" exists and contains the proper implementation. This path should correspond to the actual location of the Menu component in your codebase.
🏁 Script executed:
#!/bin/bash # Description: Check if the Menu component file exists at the specified path if [ -f "packages/ui/Menu/Menu.tsx" ]; then echo "✅ Menu component file exists at the specified path" else echo "❌ Menu component file not found at packages/ui/Menu/Menu.tsx" # Try to find where the Menu component might be located fd "Menu.tsx" --type f fiLength of output: 149
Menu Component File Path Verified
- Confirmed that the file at
"packages/ui/Menu/Menu.tsx"exists and contains the expected implementation.- No further changes are required.
2-2:✅ Verification successful
Verify the schema URL validity
Ensure that the schema URL "https://ui.shadcn.com/schema/registry-item.json" is valid and accessible. This is important for validation of registry components.
🏁 Script executed:
#!/bin/bash # Description: Check if the schema URL is accessible curl -s -o /dev/null -w "%{http_code}" "https://ui.shadcn.com/schema/registry-item.json"Length of output: 92
Schema URL Verified – No Action Needed
The URL "https://ui.shadcn.com/schema/registry-item.json" returns HTTP 200, confirming its validity and accessibility. No modifications are required in the menu.json file.
content/docs/components/select.mdx (2)
16-37: Improved installation documentation with multi-option approach.The new
<ComponentInstall>component provides a cleaner, more structured approach to installation instructions with tabbed interface. The CLI option now makes it easy for users to install via shadcn, aligning perfectly with the PR objective.
19-20:✅ Verification successful
Verify the registry URL path is correctly implemented.
The installation command uses the URL
https://retroui.dev/r/select.jsonwhich should point to the correct registry file for this component.
🏁 Script executed:
#!/bin/bash # Verify that the select.json registry file exists and is properly formatted if [ -f "public/r/select.json" ]; then echo "✅ select.json exists in the registry" # Check if the file contains basic required fields grep -q '"name": "select"' "public/r/select.json" && echo "✅ Component name is correct" || echo "❌ Missing or incorrect component name" grep -q '"type": "registry:component"' "public/r/select.json" && echo "✅ Component type is correct" || echo "❌ Missing or incorrect component type" else echo "❌ select.json does not exist in the registry" fiLength of output: 358
Registry URL verification passed – no changes needed.
The registry file at
public/r/select.jsonexists and contains the correct"name": "select"and"type": "registry:component"values, confirming that the URLhttps://retroui.dev/r/select.jsonis correctly implemented.public/r/switch.json (1)
1-14: Well-structured registry configuration for the Switch component.The JSON configuration follows the shadcn registry schema format and includes all necessary information for component installation. The component itself is properly implemented using Radix UI primitives.
public/r/label.json (1)
1-14: Properly configured Label component for shadcn registry.The Label component is well-structured and follows the shadcn registry format. The component implementation is clean and makes appropriate use of Radix UI primitives and class-variance-authority.
content/docs/components/badge.mdx (3)
11-31: Installation instructions reorganized for better user experience.The new tabbed interface for installation instructions provides a cleaner, more user-friendly documentation structure. The CLI option aligns with the PR's core objective of enabling shadcn installation.
36-37: Better organization with Examples section heading.The addition of an "Examples" section heading improves the document structure and makes it easier to navigate.
14-14:✅ Verification successful
Verify the badge registry URL is correctly implemented.
The installation command references
https://retroui.dev/r/badge.jsonwhich should correspond to a properly defined registry file.
🏁 Script executed:
#!/bin/bash # Verify that the badge.json registry file exists and is properly formatted if [ -f "public/r/badge.json" ]; then echo "✅ badge.json exists in the registry" # Check if the file contains basic required fields grep -q '"name": "badge"' "public/r/badge.json" && echo "✅ Component name is correct" || echo "❌ Missing or incorrect component name" grep -q '"type": "registry:component"' "public/r/badge.json" && echo "✅ Component type is correct" || echo "❌ Missing or incorrect component type" else echo "❌ badge.json does not exist in the registry" fiLength of output: 352
Badge registry URL verified successfully.
The verification confirms that:
public/r/badge.jsonexists in the registry.- The file contains the correct
"name": "badge"and"type": "registry:component"fields.No further modifications are required.
components/ComponentShowcase.tsx (3)
15-15: Enhanced tab styling with border bottom for visual clarity.The updated TabList styling with border-bottom and margin improves the visual separation between the tabs and content.
16-16: Improved tab styling for better visual hierarchy.The updated Tab styling creates a more visually cohesive tab interface with better indication of the active state through border styling rather than background color.
19-19: Consistent styling applied to Code tab.The same improved styling has been consistently applied to the Code tab, maintaining visual uniformity across the interface.
public/r/badge.json (1)
1-14: JSON Schema Conformance & StructureThe new registry entry for the “Badge” component is well-formed and adheres to the expected JSON schema. All required fields (schema URL, name, type, title, description, and files) are correctly defined.
content/docs/components/text.mdx (1)
32-37: Enhanced CLI Installation InstructionsThe installation section now uses the
<ComponentInstall>wrapper with a dedicated<ComponentInstall.Cli>subcomponent. The provided commandnpx shadcn@latest add "https://retroui.dev/r/text.json"is clear and correctly formatted.
public/r/checkbox.json (1)
1-14: New Checkbox Component Registry EntryThis registry file for the “Checkbox” component follows the established format. The file correctly specifies the component metadata and includes a complete TypeScript implementation inside the
contentproperty. The consistent use of theregistry:componenttype and reference to the implementation file is on point.content/docs/components/radio.mdx (1)
16-35: Consistent Installation Instructions for Radio ComponentThe newly introduced
<ComponentInstall>section for the Radio component is implemented as expected. Both the CLI instructionnpx shadcn@latest add "https://retroui.dev/r/radio.json"and the manual dependency installation steps are clearly laid out. The overall formatting and structure align well with other components’ documentation.
content/docs/components/accordion.mdx (1)
16-36: Structured Accordion Installation GuideThe Accordion documentation now features a neatly organized installation section using
<ComponentInstall>, with separate<ComponentInstall.Cli>and<ComponentInstall.Manual>sections. The CLI commandnpx shadcn@latest add "https://retroui.dev/r/accordion.json"is clear, and the manual instructions (including dependency installation and code copying guidance) are easy to follow. This update improves the clarity and consistency of installation instructions across the docs.
public/r/tab.json (2)
1-14: Component structure and definition looks good!The Tab component registry definition is well-structured with proper metadata, schema reference, and implementation details. The component appears to be built on top of HeadlessUI, which is a good choice for accessible UI components.
10-10: Well-structured Tabs implementation with reusable subcomponentsThe component structure follows good practices by breaking down functionality into logical subcomponents:
Tabs,TabsPanels,TabsTrigger,TabsContent, andTabsTriggerList. The styling is consistent with the RetroUI design system, using border styles and clear selected states.content/docs/components/menu.mdx (2)
16-35: Improved installation documentation with tabbed interfaceThe new tabbed installation interface provides a better user experience by clearly separating CLI-based installation from manual installation. This is much more organized than the previous approach.
19-19:✅ Verification successful
Verify the registry endpoint URL for consistency
The command uses the actual domain (
retroui.dev), which matches with the PR objectives. Just ensure this URL pattern is consistent across all component documentation.
🏁 Script executed:
#!/bin/bash # Check if all component documentation files use the same registry URL pattern # Search for the registry URL pattern in documentation files rg -A 1 'npx shadcn@latest add' content/docs/components/Length of output: 1986
Consistent registry endpoint confirmed
The registry URL (
https://retroui.dev/r/…) used in this command has been verified across all component documentation files and is consistent with the intended pattern. No modifications are required.public/r/input.json (1)
1-14: Input component registry definition looks goodThe overall structure of the Input registry item is well-defined with appropriate metadata.
config/components.ts (3)
8-8: Good addition of dependencies fieldAdding an optional dependencies field to the component configuration is a good enhancement that will help users know what packages they need to install for each component.
23-23: Dependencies for accordion component look correctThe dependencies for the accordion component (
@radix-ui/react-accordionandlucide-react) are accurately specified.
56-56: Updated file path for Input componentThe file path for the Input component has been correctly updated to match its new location in the directory structure (
packages/ui/Form/Input.tsx).public/r/button.json (1)
1-14: Component registry entry looks good.
The JSON file correctly adheres to the registry schema, specifying metadata (name, type, title, description) and the file details for the Button component. Ensure that the multiline string in the "content" field is properly escaped and renders as expected in consuming tools.content/docs/components/avatar.mdx (1)
11-31: Refactored MDX installation instructions using ComponentInstall.
The installation instructions for the Avatar component have been neatly encapsulated within the<ComponentInstall>wrapper (with its CLI and manual subcomponents). This not only improves clarity but also provides a consistent experience across component docs. Please double-check that the closing tags (especially for<ComponentInstall.Manual>) are correctly placed so the layout renders as intended.public/r/alert.json (1)
1-14: Alert component registry entry is well-structured.
The JSON metadata for the Alert component—including its schema declaration, component name, type, title, and description—is clearly defined. The embedded "content" field correctly contains the implementation details. It might be worthwhile to verify that the styling variants align with your overall design tokens, but otherwise the implementation looks solid.public/r/text.json (1)
1-14: Text component registry entry appears correct.
This registry entry for the Text component is concise and adheres to the expected schema. The content string embeds the TypeScript implementation properly, defining the variant rules and default behaviors. Just ensure that these styles and the variants (especially theasprop handling) continue to integrate smoothly with your UI framework.content/docs/components/button.mdx (1)
11-26: Enhanced installation instructions via ComponentInstall.
The refactoring of the Button component documentation now leverages<ComponentInstall>with dedicated CLI and Manual sections. This organized layout streamlines the installation process for users. Verify that the CLI command (npx shadcn@latest add "https://retroui.dev/r/button.json") and the manual dependency instruction (npm install class-variance-authority) are accurate and reflect the intended setup.content/docs/components/alert.mdx (1)
11-31: Excellent implementation of the new installation UI!The new
<ComponentInstall>component provides a clear, organized interface with tabbed navigation between CLI and manual installation methods. This significantly improves the documentation usability and aligns perfectly with the PR objective of enabling installation through the shadcn registry.content/docs/components/dialog.mdx (2)
16-49: Well-structured installation component implementation!The new tabbed interface for installation instructions improves the documentation's clarity and consistency across components, making it easier for users to choose their preferred installation method.
56-76: Improved heading structure and namingThe heading level changes from "####" to "###" and the simplified section titles (e.g., "Confirm dialog with footer" to "With footer") improve readability while maintaining a consistent documentation style.
public/r/avatar.json (1)
1-14:✅ Verification successful
Well-structured registry item for the Avatar component
The registry item follows the shadcn schema correctly and includes comprehensive metadata and implementation details for the Avatar component.
🏁 Script executed:
#!/bin/bash # Check for the imported utility file that Avatar component depends on echo "Checking for the required utility file..." cat $(fd --type f --full-path "lib/utils" --exec echo {})Length of output: 337
Approval: The Avatar Registry Item and Component are Valid
The registry item defined in
public/r/avatar.jsoncorrectly follows the shadcn schema, and the comprehensive metadata and component implementation (including sub-components and dependency on thecnutility in./lib/utils.ts) are valid.
- The referenced utility file (
./lib/utils.ts) exists and implements thecnfunction properly.- The code snippet from the Avatar component is structured as expected.
public/r/accordion.json (1)
1-14: Well-structured registry item for the Accordion componentThe registry item follows the shadcn schema correctly and includes comprehensive metadata and implementation details for the Accordion component.
components/ComponentInstall.tsx (2)
16-31: Well-designed tabbed interface for installation optionsThe component provides a clean, user-friendly interface for displaying both CLI and manual installation methods. The tab design is consistent with modern UX patterns and enhances the documentation's readability.
33-38: Good use of Object.assign for component compositionUsing
Object.assignto attach the subcomponents to the main component creates a clean, intuitive API for component consumers. This approach maintains the relationship between the parent and child components while providing a clear namespace.public/r/card.json (1)
1-14: Approved: Clean Registry Definition for Card Component
This new JSON file clearly defines the Card component entry using the proper registry schema. The metadata (name, type, title, description) and the file reference topackages/ui/Cards/Card.tsxare all appropriately set. The embedded TypeScript code uses a standard pattern—defining subcomponents (Header, Title, Description, Content) and combining them withObject.assign—which improves modularity and reusability.public/r/select.json (1)
1-14: Approved: Well-Structured Select Component Registry
This new JSON entry for the Select component is well documented. The metadata, file reference topackages/ui/Form/Select.tsx, and the embedded TypeScript implementation (including subcomponents like Trigger, Value, Icon, Content, Group, Item, Label, and Separator) follow a clear and modular design. The use of Radix UI and utility functions ensures consistency with other components in the registry.
| "files": [ | ||
| { | ||
| "path": "packages/ui/Form/Switch.tsx", | ||
| "content": "\"use client\";\n\nimport * as React from \"react\";\nimport * as SwitchPrimitives from \"@radix-ui/react-switch\";\n\nimport { cn } from \"@/lib/utils\";\n\nconst Switch = ({ className, ...props }: SwitchPrimitives.SwitchProps) => (\n <SwitchPrimitives.Root\n className={cn(\n \"peer inline-flex h-6 w-11 shrink-0 cursor-pointer border-2 border-foreground items-center disabled:cursor-not-allowed disabled:opacity-50 data-[state=checked]:bg-primary-400\",\n className\n )}\n {...props}\n >\n <SwitchPrimitives.Thumb\n className={cn(\n \"pointer-events-none block h-4 w-4 bg-primary-500 border-2 mx-0.5 border-foreground shadow-lg ring-0 transition-transform data-[state=checked]:translate-x-5 data-[state=unchecked]:translate-x-0 data-[state=checked]:bg-background\"\n )}\n />\n </SwitchPrimitives.Root>\n);\n\nexport { Switch };\n", |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Verify the import path for utility function.
The component imports cn from @/lib/utils, which assumes a specific project structure. Ensure this path is correct for users installing this component through shadcn.
🏁 Script executed:
#!/bin/bash
# Check if the utils library is accessible through the specified import path
# Look for the utils.ts file
utils_file=$(find . -type f -path "*/lib/utils.ts" -o -path "*/lib/utils.tsx" -o -path "*/lib/utils.js" -o -path "*/lib/utils.jsx" | head -1)
if [ -n "$utils_file" ]; then
echo "✅ Utils file found at: $utils_file"
# Check if the 'cn' function is exported
grep -q "export.*cn" "$utils_file" && echo "✅ 'cn' function is exported from utils" || echo "❌ 'cn' function not found in utils"
else
echo "❌ Utils file not found at the expected path. Import path @/lib/utils may not work for users."
fiLength of output: 870
Action Required: Correct the Utility Function Import Path
- The current import of
cnfrom@/lib/utilsis resolving to a file in the node_modules directory (specifically from the@contentlayer/clipackage), which does not export acnfunction. - This suggests that the expected project-specific utility file (typically located in something like
src/lib/utils) is not being referenced. As a result, users installing this component via shadcn might encounter issues. - Please verify the correct location for the
cnutility and update the import path accordingly.
| "files": [ | ||
| { | ||
| "path": "packages/ui/Form/Input.tsx", | ||
| "content": "import React, { InputHTMLAttributes } from \"react\";\n\ninterface InputProps extends InputHTMLAttributes<HTMLInputElement> {\n className?: string;\n}\n\nexport const Input: React.FC<InputProps> = ({\n type = \"text\",\n placeholder = \"Enter text\",\n className = \"\",\n ...props\n}) => {\n console.log(props);\n return (\n <input\n type={type}\n placeholder={placeholder}\n className={`px-4 py-2 w-full border-2 border-black shadow-md transition focus:outline-none focus:shadow-xs ${\n props[\"aria-invalid\"]\n ? \"border-red-500 text-red-500 shadow-xs shadow-red-600\"\n : \"\"\n } ${className}`}\n {...props}\n />\n );\n};\n", |
There was a problem hiding this comment.
Remove debugging console.log statement
There's a console.log(props) statement in the Input component implementation. This should be removed before merging as it's not appropriate for production code and could leak sensitive information to the browser console.
Apply this change:
interface InputProps extends InputHTMLAttributes<HTMLInputElement> {
className?: string;
}
export const Input: React.FC<InputProps> = ({
type = "text",
placeholder = "Enter text",
className = "",
...props
}) => {
- console.log(props);
return (
<input
type={type}
placeholder={placeholder}
className={`px-4 py-2 w-full border-2 border-black shadow-md transition focus:outline-none focus:shadow-xs ${
props["aria-invalid"]
? "border-red-500 text-red-500 shadow-xs shadow-red-600"
: ""
} ${className}`}
{...props}
/>
);
};📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| "content": "import React, { InputHTMLAttributes } from \"react\";\n\ninterface InputProps extends InputHTMLAttributes<HTMLInputElement> {\n className?: string;\n}\n\nexport const Input: React.FC<InputProps> = ({\n type = \"text\",\n placeholder = \"Enter text\",\n className = \"\",\n ...props\n}) => {\n console.log(props);\n return (\n <input\n type={type}\n placeholder={placeholder}\n className={`px-4 py-2 w-full border-2 border-black shadow-md transition focus:outline-none focus:shadow-xs ${\n props[\"aria-invalid\"]\n ? \"border-red-500 text-red-500 shadow-xs shadow-red-600\"\n : \"\"\n } ${className}`}\n {...props}\n />\n );\n};\n", | |
| import React, { InputHTMLAttributes } from "react"; | |
| interface InputProps extends InputHTMLAttributes<HTMLInputElement> { | |
| className?: string; | |
| } | |
| export const Input: React.FC<InputProps> = ({ | |
| type = "text", | |
| placeholder = "Enter text", | |
| className = "", | |
| ...props | |
| }) => { | |
| return ( | |
| <input | |
| type={type} | |
| placeholder={placeholder} | |
| className={`px-4 py-2 w-full border-2 border-black shadow-md transition focus:outline-none focus:shadow-xs ${ | |
| props["aria-invalid"] | |
| ? "border-red-500 text-red-500 shadow-xs shadow-red-600" | |
| : "" | |
| } ${className}`} | |
| {...props} | |
| /> | |
| ); | |
| }; |
| { | ||
| "$schema": "https://ui.shadcn.com/schema/registry-item.json", | ||
| "name": "dialog", | ||
| "type": "registry:component", | ||
| "title": "Dialog", | ||
| "description": "An impactful dialog that ensures your important messages and actions get the attention they deserve! 💬✨", | ||
| "files": [ | ||
| { | ||
| "path": "packages/ui/Dialog/Dialog.tsx", | ||
| "content": "\"use client\";\n\nimport * as ReactDialog from \"@radix-ui/react-dialog\";\nimport { cn } from \"@/lib/utils\";\nimport { cva, VariantProps } from \"class-variance-authority\";\nimport React, { HTMLAttributes, ReactNode } from \"react\";\nimport { VisuallyHidden } from \"@radix-ui/react-visually-hidden\";\nimport { X } from \"lucide-react\";\n\nconst Dialog = ReactDialog.Root;\nconst DialogTrigger = ReactDialog.Trigger;\n\nconst overlayVariants = cva(\n ` fixed bg-black/80 font-head\n data-[state=open]:fade-in-0\n data-[state=open]:animate-in \n data-[state=closed]:animate-out \n data-[state=closed]:fade-out-0 \n `,\n {\n variants: {\n variant: {\n default: \"inset-0 z-50 bg-black/80\",\n none: \"fixed bg-transparent\",\n },\n },\n defaultVariants: {\n variant: \"default\",\n },\n }\n);\n\ninterface IDialogBackgroupProps\n extends HTMLAttributes<HTMLDivElement>,\n VariantProps<typeof overlayVariants> {}\n\nconst DialogBackdrop = React.forwardRef<HTMLDivElement, IDialogBackgroupProps>(\n (inputProps: IDialogBackgroupProps, forwardedRef) => {\n const { variant = \"default\", className, ...props } = inputProps;\n\n return (\n <ReactDialog.Overlay\n className={cn(overlayVariants({ variant }), className)}\n {...props}\n />\n );\n }\n);\n\nconst dialogVariants = cva(\n `fixed z-50 left-1/2 top-1/2 -translate-x-1/2 -translate-y-1/2 \n flex flex-col border-2 border-black shadow-md gap-4 overflow-y-auto bg-white\n w-full h-fit max-h-[80vh] max-w-[97%] duration-300\n data-[state=open]:animate-in \n data-[state=open]:slide-in-from-left-1/2 \n data-[state=open]:slide-in-from-top-[48%]\n data-[state=open]:fade-in-0 \n data-[state=open]:zoom-in-95 \n data-[state=closed]:animate-out \n data-[state=closed]:fade-out-0 \n data-[state=closed]:slide-out-to-top-[48%] \n data-[state=closed]:slide-out-to-left-1/2 \n data-[state=closed]:zoom-out-95`,\n {\n variants: {\n size: {\n auto: \"max-w-fit\",\n sm: \"lg:max-w-[30%]\",\n md: \"lg:max-w-[40%]\",\n lg: \"lg:max-w-[50%]\",\n xl: \"lg:max-w-[60%]\",\n \"2xl\": \"lg:max-w-[70%]\",\n \"3xl\": \"lg:max-w-[80%]\",\n \"4xl\": \"lg:max-w-[90%]\",\n screen: \"max-w-[100%]\",\n },\n },\n defaultVariants: {\n size: \"auto\",\n },\n }\n);\n\ninterface IDialogContentProps\n extends HTMLAttributes<HTMLDivElement>,\n VariantProps<typeof dialogVariants> {\n overlay?: IDialogBackgroupProps;\n}\n\nconst DialogContent = React.forwardRef<HTMLDivElement, IDialogContentProps>(\n (inputProps: IDialogContentProps, forwardedRef) => {\n const {\n children,\n size = \"auto\",\n className,\n overlay,\n ...props\n } = inputProps;\n\n return (\n <ReactDialog.Portal>\n <DialogBackdrop {...overlay} />\n <ReactDialog.Content\n className={cn(dialogVariants({ size }), className)}\n ref={forwardedRef}\n {...props}\n >\n <VisuallyHidden>\n <ReactDialog.Title />\n </VisuallyHidden>\n <div className=\"flex flex-col relative\">{children}</div>\n </ReactDialog.Content>\n </ReactDialog.Portal>\n );\n }\n);\n\ninterface IDialogDescriptionProps extends HTMLAttributes<HTMLDivElement> {}\nconst DialogDescription = ({\n children,\n className,\n ...props\n}: IDialogDescriptionProps) => {\n return (\n <ReactDialog.Description className={cn(className)} {...props}>\n {children}\n </ReactDialog.Description>\n );\n};\n\nconst dialogFooterVariants = cva(\n \"flex items-center justify-end border-t-2 border-black min-h-12 gap-4 px-4 py-2\",\n {\n variants: {\n variant: {\n default: \"bg-white text-black\",\n },\n position: {\n fixed: \"sticky bottom-0\",\n static: \"static\",\n },\n },\n defaultVariants: {\n position: \"fixed\",\n },\n }\n);\n\nexport interface IDialogFooterProps\n extends HTMLAttributes<HTMLDivElement>,\n VariantProps<typeof dialogFooterVariants> {}\n\nconst DialogFooter = ({\n children,\n className,\n position,\n variant,\n ...props\n}: IDialogFooterProps) => {\n return (\n <div\n className={cn(dialogFooterVariants({ position, variant }), className)}\n {...props}\n >\n {children}\n </div>\n );\n};\n\nconst dialogHeaderVariants = cva(\n \"flex items-center justify-between border-b-2 border-black px-4 min-h-12\",\n {\n variants: {\n variant: {\n default: \"bg-primary-400 text-black\",\n },\n position: {\n fixed: \"sticky top-0\",\n static: \"static\",\n },\n },\n defaultVariants: {\n variant: \"default\",\n position: \"static\",\n },\n }\n);\n\nconst DialogHeaderDefaultLayout = ({ children }: { children: ReactNode }) => {\n return (\n <>\n {children}\n <DialogTrigger title=\"Close pop-up\" className=\"cursor-pointer\" asChild>\n <X />\n </DialogTrigger>\n </>\n );\n};\n\ninterface IDialogHeaderProps\n extends HTMLAttributes<HTMLDivElement>,\n VariantProps<typeof dialogHeaderVariants>,\n ReactDialog.DialogTitleProps {}\n\nconst DialogHeader = ({\n children,\n className,\n position,\n variant,\n asChild,\n ...props\n}: IDialogHeaderProps) => {\n return (\n <div\n className={cn(dialogHeaderVariants({ position, variant }), className)}\n {...props}\n >\n {asChild ? (\n children\n ) : (\n <DialogHeaderDefaultLayout>{children}</DialogHeaderDefaultLayout>\n )}\n </div>\n );\n};\n\nconst DialogComponent = Object.assign(Dialog, {\n Trigger: DialogTrigger,\n Header: DialogHeader,\n Content: DialogContent,\n Description: DialogDescription,\n Footer: DialogFooter,\n});\n\nexport { DialogComponent as Dialog };\n", | ||
| "type": "registry:component" | ||
| } | ||
| ] | ||
| } No newline at end of file |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Nitpick: Rename Typo in TypeScript Interface Naming
The registry entry for the Dialog component is comprehensive and the embedded code correctly uses Radix UI and class-variance-authority. One minor issue is the interface name IDialogBackgroupProps (lines within the embedded content). This appears to be a typo; renaming it to IDialogBackdropProps would improve clarity and maintain consistency with common terminology. Consider applying the following change in the referenced file packages/ui/Dialog/Dialog.tsx:
- interface IDialogBackgroupProps extends HTMLAttributes<HTMLDivElement>, VariantProps<typeof overlayVariants> {}
+ interface IDialogBackdropProps extends HTMLAttributes<HTMLDivElement>, VariantProps<typeof overlayVariants> {}Committable suggestion skipped: line range outside the PR's diff.
install components through shadcn registry
ex:
npx shadcn@latest add "https://retroui.dev/r/button.json"Summary by CodeRabbit