packages/ui-cli/README.md (1)

5-82: Replace entire usage documentation with correct information.

All the documented commands (init, set-root, setup, watch) don't exist in the actual CLI implementation. The documentation should match the actual add command functionality.

Replace with documentation for the actual CLI:

 ## Installation

-```sh
-npm install --global @clerk/dev-cli
-```
+```sh
+npm install --global @clerk/ui
+```

-If you haven't already, install `turbo` globally.
+## Usage

-```sh
-npm install --global turbo
-```
+Add Clerk shadcn/ui components to your project:

-## First time setup
-
-After installing `@clerk/dev` globally, you'll need to initialise a configuration file and tell the CLI where to find your local copy of the `clerk/javascript` repository.
-
-1.  Initialise the configuration file which will be located at `~/.config/clerk/dev.json`:
-
-        ```shell
-        clerk-dev init
-        ```
-
-2.  Navigate to your local clone of `clerk/javascript` and run `set-root`:
-
-        ```shell
-        clerk-dev set-root
-        ```
-
-You're all set now to run the day-to-day commands 🎉
-
-## Adding instances & changing the configuration
-
-During the first time setup a `~/.config/clerk/dev.json` file was created. Its object contains a `activeInstance` and `instances` key. You can add additional instances by adding a new key to the `instances` object.
-
-You can use the `set-instance` command to switch between `activeInstance` afterwards:
-
-```shell
-clerk-dev set-instance yourName
-```
-
-## Per-Project Setup
-
-In each project you'd like to use with the monorepo versions of Clerk packages, `clerk-dev` can perform one-time framework setup such as installing the monorepo versions of packages and configuring the framework to use your Clerk keys.
-
-To perform framework setup, run:
-
-```sh
-clerk-dev setup
-```
-
-If you aren't working on `@clerk/clerk-js`, and do not want to customize the `clerkJSUrl`, pass `--no-js`.
-
 ```sh
-clerk-dev setup --no-js
+npx @clerk/ui add button card

-If you want to skip the installation of monorepo versions of packages, pass --skip-install.
+Add a single component:

-clerk-dev setup --skip-install
+npx @clerk/ui add form-field

-## Running

-Once your project has been configured to use the monorepo versions of your dependencies, you can start the watchers for each dependency by running:

-sh -clerk-dev watch -

-This will run the build task for any @clerk/* packages in the package.json of the current working directory, including any of their dependencies.

-If you do not want to start the watcher for @clerk/clerk-js, you can instead pass --no-js.

-sh -clerk-dev watch --no-js -
+This will fetch the component configuration from Clerk's registry and install it using shadcn/ui.

</blockquote></details>

</blockquote></details>

<details>
<summary>🧹 Nitpick comments (3)</summary><blockquote>

<details>
<summary>packages/ui-cli/bin/cli.js (2)</summary><blockquote>

`5-10`: **Enhance error handling and usage information.**

The argument validation works but could be improved for better user experience.



Consider providing more detailed usage information and validating package names:

```diff
 if (args.length < 2 || args[0] !== 'add') {
-  console.log('Usage: npx @clerk/ui add [...packages]');
+  console.error('Usage: npx @clerk/ui add [...packages]');
+  console.error('');
+  console.error('Examples:');
+  console.error('  npx @clerk/ui add button card');
+  console.error('  npx @clerk/ui add form-field');
   process.exit(1);
 }

---

12-19: Consider adding package name validation.

The current validation only checks for empty strings, but package names typically follow specific conventions.

Add basic package name validation:

 for (const packageName of packageNames) {
-  if (!packageName.trim()) {
+  const trimmedName = packageName.trim();
+  if (!trimmedName) {
     continue;
   }
+  
+  // Basic validation for package names (alphanumeric, hyphens, underscores)
+  if (!/^[a-z0-9-_]+$/i.test(trimmedName)) {
+    console.error(`Warning: "${trimmedName}" may not be a valid component name`);
+  }

-  console.log(`Adding ${packageName} component...`);
+  console.log(`Adding ${trimmedName} component...`);

packages/ui-cli/README.md (1)

23-24: Fix markdown code block formatting.

Use fenced code blocks instead of indented blocks for consistency.

-        ```shell
-        clerk-dev init
-        ```
+```shell
+clerk-dev init
+```

-        ```shell
-        clerk-dev set-root
-        ```
+```shell
+clerk-dev set-root
+```

Also applies to: 29-30

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

packages/ui-cli/src/cli.js (2)

13-16: Add comprehensive input validation for package names.

While the empty string check is good, consider adding more robust input validation to prevent potential issues with malformed package names or security concerns.

Add comprehensive validation:

   for (const packageName of packageNames) {
-    if (!packageName.trim()) {
+    const trimmedName = packageName.trim();
+    if (!trimmedName) {
       continue;
     }
+    
+    // Validate package name format to prevent issues
+    if (!/^[a-z0-9][a-z0-9-]*[a-z0-9]$/.test(trimmedName) && trimmedName.length > 1) {
+      console.error(`Error: Invalid package name "${trimmedName}". Package names should contain only lowercase letters, numbers, and hyphens.`);
+      process.exit(1);
+    }

---

3-34: Add comprehensive test coverage for the CLI functionality.

No tests were added as part of this PR. According to coding guidelines, tests should be added to cover the new functionality.

Consider adding tests to cover:

• Argument validation and error cases
• URL construction with various package names
• Error handling when shadcn command fails
• Success scenarios with mocked execSync
• Input sanitization edge cases

Would you like me to generate a test suite structure for this CLI tool?

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

packages/ui-cli/src/__tests__/cli.spec.js (1)

1-16: Consider more specific typing for test variables.

The test setup and imports look good. However, the JSDoc type annotations using @type {any} could be more specific to improve type safety and IDE support.

Consider this improvement:

-  /** @type {any} */
+  /** @type {{ log: import('vitest').MockInstance, error: import('vitest').MockInstance }} */
   let consoleSpy;
-  /** @type {any} */
+  /** @type {import('vitest').MockInstance} */
   let processExitSpy;
-  /** @type {any} */
+  /** @type {string[]} */
   let originalArgv;

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro