[Feature Request] Monorepo support (parity with shadcn-ui React v2)

### Prerequisites - [x] This feature already exists in [shadcn/ui](https://github.com/shadcn/ui) - if not, it won't be considered here so don't continue with your issue. ### Describe the feature ## Summary `shadcn-svelte` currently assumes a single-project structure with one `components.json` at the project root. For monorepo workflows (pnpm workspaces, Turborepo, Nx), this design conflicts with the common need to share UI primitives across multiple apps in the same repository. The React equivalent — [`shadcn-ui`](https://ui.shadcn.com) — added [monorepo support](https://ui.shadcn.com/docs/monorepo) in v2, which solved the same problem for React/Next.js multi-app projects. It would be great to bring parity to the Svelte CLI. ## Problem In a typical Svelte monorepo: \`\`\` my-monorepo/ ├── apps/ │ ├── site-a/ ← Svelte app │ └── site-b/ ← Svelte app (similar features, different brand) └── packages/ └── shared-ui/ ← Would like to share shadcn primitives here \`\`\` Current options are all painful: 1. **Per-app primitives** — each app runs `shadcn-svelte add` separately and ends up with its own copy of `lib/components/ui/`. Over time these diverge, requiring manual sync across apps. 2. **Hand-modify `components.json` + paths** — fragile; breaks on shadcn-svelte CLI updates, and the CLI doesn't know how to resolve workspace-relative aliases properly. 3. **Drop shadcn-svelte entirely** — use `bits-ui` directly with custom Tailwind wrappers placed in `packages/shared-ui/`. Works for monorepo, but loses the curated primitive library, future updates, and ecosystem. For developers maintaining multi-site Svelte frameworks (white-label sites, multi-tenant projects, group of related products), this is significant friction. ## Reference: React `shadcn-ui` monorepo support The React implementation provides: - Workspace auto-detection (pnpm / yarn / npm workspaces) - Per-workspace `components.json` with workspace-relative aliases - `--cwd` / target flags for CLI to install into a specific package - Smart resolution of dependencies across workspace packages Docs: <https://ui.shadcn.com/docs/monorepo> ## Proposed for `shadcn-svelte` Bring parity: ### 1. CLI workspace awareness \`\`\`sh # Init into a specific workspace package pnpm dlx shadcn-svelte@latest init --cwd packages/shared-ui # Add components into a specific workspace pnpm dlx shadcn-svelte@latest add button --cwd packages/shared-ui \`\`\` ### 2. Per-workspace `components.json` Each workspace package can have its own `components.json` with aliases that resolve via the workspace name: \`\`\`json { "$schema": "https://shadcn-svelte.com/schema.json", "style": "default", "tailwind": { ... }, "aliases": { "components": "@my-org/shared-ui/components", "utils": "@my-org/shared-ui/utils", "ui": "@my-org/shared-ui/components/ui", "lib": "@my-org/shared-ui/lib", "hooks": "@my-org/shared-ui/hooks" } } \`\`\` ### 3. Auto-detection When the CLI runs in a monorepo context (detects `pnpm-workspace.yaml` / workspaces in `package.json`), it should suggest the target workspace or use `--cwd`. ### 4. Documentation A dedicated guide equivalent to the React version, showing typical monorepo setups (pnpm workspaces + Turborepo, etc.). ## Use case I'm building a multi-site framework for Asian lottery sites (4+ sites, similar features, different brands). The current options force me to either: - Maintain N separate repos with manual sync of UI primitives (current path, painful), or - Force everything into a monorepo + abandon shadcn-svelte (loses ecosystem) Monorepo support in `shadcn-svelte` would let me share UI components across sites while still benefiting from the curated primitive library and future updates — without giving up the per-app customization shadcn philosophy enables. ## Additional context This appears to be a recurring discussion in the community — searching GitHub for "shadcn-svelte monorepo" returns multiple threads / blog posts where developers hit the same wall. Bringing parity with React `shadcn-ui` would substantially improve adoption in monorepo contexts (which are increasingly common for Svelte teams maintaining multiple related apps). Happy to help with testing / feedback if the team prioritizes this. Thanks for the great library!