@dryui/ui 0.1.6 → 0.1.7

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -5,291 +5,178 @@ description: 'Use when building UIs with DryUI (@dryui/ui) Svelte 5 components.
5
5
 
6
6
  # DryUI
7
7
 
8
- ## Overview
8
+ Zero-dependency Svelte 5 components. All imports from `@dryui/ui`. Requires a theme CSS import. Svelte 5 runes only.
9
9
 
10
- DryUI is a library of zero-dependency Svelte 5 components. All components import from `@dryui/ui`. Components are headless primitives with styled defaults via CSS modules and `--dry-*` CSS variables. A theme import is required for components to render correctly.
10
+ **Tradeoff:** These rules bias toward correctness over speed. For throwaway prototypes, use judgment.
11
11
 
12
- Key facts:
12
+ ## 1. Look Up Before You Write
13
13
 
14
- - Svelte 5 runes only (`$state`, `$derived`, `$props`) -- no legacy syntax
15
- - Requires theme: `import '@dryui/ui/themes/default.css'` (or `dark.css`)
16
- - Prefer `<html class="theme-auto">` as the default theme mode; only set `data-theme="light|dark"` for explicit overrides
17
- - No external runtime dependencies
14
+ **Never guess a component API. Always verify first.**
18
15
 
19
- ## Quick Start (new SvelteKit project)
16
+ - Call `info` or `compose` before using any component for the first time
17
+ - Component APIs vary — `bind:value`, `bind:open`, `bind:checked` are NOT interchangeable
18
+ - Compound vs simple, required parts, available props — all differ per component
19
+ - If you skip the lookup, you'll write plausible-looking code that silently breaks
20
20
 
21
- Run the install planner it detects the project and returns a tailored
22
- step-by-step plan:
21
+ The test: can you point to an `info` or `compose` call for every component in your output?
23
22
 
24
- ```
25
- npx -y @dryui/cli install --json
26
- ```
27
-
28
- Execute each `"pending"` step in the returned JSON (install package, edit/create
29
- files). Then verify:
30
-
31
- ```
32
- npx -y @dryui/cli detect --json
33
- ```
34
-
35
- The output should show `"status": "ready"`.
36
-
37
- ### Manual setup (if you prefer)
38
-
39
- 1. `bun add @dryui/ui` (or npm/pnpm/yarn equivalent)
40
- 2. In `src/app.html`, add `class="theme-auto"` to the `<html>` tag (preserving
41
- existing attributes like `lang="en"`)
42
- 3. In your root layout (`src/routes/+layout.svelte`), add theme imports to the
43
- existing `<script>` block — do not create a second `<script>`:
44
- ```svelte
45
- <script>
46
- import '@dryui/ui/themes/default.css';
47
- import '@dryui/ui/themes/dark.css';
48
- </script>
49
- ```
50
- 4. Import `app.css` AFTER theme CSS if you have custom styles
51
- 5. (Optional) Override semantic tokens in `app.css` — use the layered token system documented in `rules/theming.md`
52
-
53
- > **Local dev:** If `@dryui/ui` is not on npm, link from the monorepo:
54
- > `cd /path/to/dryui/packages/ui && bun link && cd /your/project && bun link @dryui/ui`
23
+ ## 2. Everything is Compound Until Proven Otherwise
55
24
 
56
- ## Critical Rules
25
+ **Use `.Root`. Always check.**
57
26
 
58
- ### Rule 1: Compound components MUST use .Root
27
+ Most DryUI components are compound they require `<Card.Root>`, not `<Card>`. The bare name silently fails or renders wrong. Assume compound; verify with `info`.
59
28
 
60
29
  ```svelte
61
- <!-- Incorrect -->
62
- <Card>content</Card>
63
-
64
- <!-- Correct -->
65
- <Card.Root>content</Card.Root>
30
+ <!-- Wrong --> <Card>content</Card>
31
+ <!-- Right --> <Card.Root>content</Card.Root>
66
32
  ```
67
33
 
68
- Compound components include Accordion, Alert, AlertDialog, Breadcrumb, Calendar, Card, Carousel, Chart, ChipGroup, Collapsible, ColorPicker, Combobox, CommandPalette, ContextMenu, DataGrid, DateField, DatePicker, DateRangePicker, DescriptionList, Dialog, DragAndDrop, Drawer, DropdownMenu, Field, Fieldset, FileSelect, FileUpload, FlipCard, FloatButton, HoverCard, InputGroup, LinkPreview, List, Listbox, Map, MegaMenu, Menubar, MultiSelectCombobox, NavigationMenu, NotificationCenter, OptionSwatchGroup, Pagination, PinInput, Popover, RadioGroup, RangeCalendar, RichTextEditor, SegmentedControl, Select, Sidebar, Splitter, StarRating, Stepper, Table, TableOfContents, Tabs, TagsInput, Timeline, Toast, ToggleGroup, Toolbar, Tooltip, Tour, Transfer, Tree, and Typography. See `rules/compound-components.md` for parts lists.
69
-
70
- ### Rule 2: Always import a theme
71
-
72
- ```svelte
73
- <script>
74
- import '@dryui/ui/themes/default.css';
75
- import '@dryui/ui/themes/dark.css';
76
- import { Button } from '@dryui/ui';
77
- </script>
78
- ```
34
+ The test: every compound component in your markup uses `.Root`, and its parts are wrapped inside it. See `rules/compound-components.md` for the full list and parts reference.
79
35
 
80
- Without a theme, components render unstyled. See `rules/theming.md` for customization.
36
+ ## 3. Let the Theme Do Its Job
81
37
 
82
- When building a theme toggle, default to system mode with `<html class="theme-auto">` and persist explicit user-selected `light` or `dark` overrides.
38
+ **Import it. Use its tokens. Don't fight it.**
83
39
 
84
- ### Rule 3: Use the correct bind: prop — it varies by component
40
+ - Import `@dryui/ui/themes/default.css` (and `dark.css`) before any component use
41
+ - Use `--dry-color-*` and `--dry-space-*` tokens — never hardcoded colors or spacing
42
+ - Don't add decorative CSS (gradients, shadows, colored borders) — the theme handles appearance
43
+ - Override semantic tokens (Tier 2) in `:root`, not component tokens (Tier 3)
44
+ - Prefer `<html class="theme-auto">` — use `data-theme="light|dark"` only for explicit overrides
85
45
 
86
- ```svelte
87
- <!-- Incorrect -->
88
- <Input value={email} />
89
- <Popover.Root bind:value={open} />
90
- <!-- wrong prop -->
46
+ ```css
47
+ /* Wrong */
48
+ .card { background: #6366f1; color: white; }
91
49
 
92
- <!-- Correct -->
93
- <Input bind:value={email} />
94
- <Popover.Root bind:open />
50
+ /* Right */
51
+ .card { background: var(--dry-color-fill-brand); color: var(--dry-color-text-strong); }
95
52
  ```
96
53
 
97
- Bindable props vary by component:
54
+ The test: does your CSS contain zero hex colors, zero `rgb()` values, and zero inline styles?
98
55
 
99
- - `bind:value` Input, Textarea, NumberInput, Slider, Rating, PinInput, Select, Combobox, Tabs, TagsInput, ColorPicker, DatePicker, RadioGroup, RichTextEditor, Accordion, ToggleGroup
100
- - `bind:checked` — Checkbox, Switch
101
- - `bind:pressed` — Toggle
102
- - `bind:open` — Popover, Dialog, Drawer, AlertDialog, DropdownMenu, ContextMenu, Select, Combobox, CommandPalette, FloatButton, DatePicker, Collapsible
103
- - `bind:active` — Tour (not `bind:open`)
104
- - `bind:files` — FileUpload
105
- - `bind:page` — Pagination
106
- - `bind:activeStep` — Stepper
107
- - `bind:sizes` — Splitter
56
+ ## 4. Grid for Layout. Container for Width. @container for Responsive.
108
57
 
109
- Select and Combobox support both `bind:value` and `bind:open`. ColorPicker also exposes `bind:alpha`. Transfer uses `bind:sourceItems` and `bind:targetItems`.
58
+ **Nothing else.**
110
59
 
111
- ### Rule 4: Use CSS grid for layout, Container for width
60
+ - All layout is `display: grid` with `--dry-space-*` tokens in scoped `<style>`
61
+ - `Container` (simple component, no `.Root`) for constrained content width
62
+ - Use `@container` queries for responsive sizing — never `@media` for layout breakpoints
63
+ - No flexbox. No inline styles. No `width`/`min-width`/`max-width` properties
112
64
 
113
65
  ```svelte
114
- <!-- Incorrect -->
115
- <div style="display: flex; gap: 1rem;">...</div>
116
-
117
- <!-- Correct — raw CSS grid in scoped <style> -->
118
66
  <div class="layout">...</div>
119
67
  <style>
120
68
  .layout { display: grid; gap: var(--dry-space-4); }
121
69
  </style>
122
70
  ```
123
71
 
124
- Use `display: grid` with `--dry-space-*` tokens for layout. Use `Container` for constrained content width. Use `@container` queries for responsive sizing — never `@media` for layout breakpoints. Do not use inline styles.
72
+ The test: grep your output for `display: flex`, `style=`, `@media` all should return nothing.
73
+
74
+ ## 5. Every Input Gets a Field.Root
75
+
76
+ **Accessibility isn't optional.**
125
77
 
126
- ### Rule 5: Wrap form inputs in Field.Root
78
+ - Wrap every form input in `Field.Root` with a `Label`
79
+ - Use `AlertDialog` (not `Dialog`) for destructive confirmations
80
+ - Add `aria-label` to every icon-only button
81
+ - Use `type="submit"` on primary form action buttons
127
82
 
128
83
  ```svelte
129
- <!-- Incorrect -->
84
+ <!-- Wrong -->
130
85
  <label>Email</label>
131
86
  <Input bind:value={email} />
132
87
 
133
- <!-- Correct -->
88
+ <!-- Right -->
134
89
  <Field.Root>
135
- <Label>Email</Label>
136
- <Input bind:value={email} />
90
+ <Label>Email</Label>
91
+ <Input bind:value={email} />
137
92
  </Field.Root>
138
93
  ```
139
94
 
140
- See `rules/accessibility.md` for ARIA details.
95
+ The test: every `<Input>`, `<Select.Root>`, `<Textarea>` is inside a `Field.Root` with a `Label` sibling.
141
96
 
142
- ### Rule 6: Use --dry-\* CSS variables, not hardcoded colors
97
+ ## 6. Prefer DryUI Over Native HTML
143
98
 
144
- ```css
145
- /* Incorrect */
146
- .card {
147
- background: #6366f1;
148
- color: white;
149
- }
150
-
151
- /* Correct */
152
- .card {
153
- background: var(--dry-color-fill-brand);
154
- color: var(--dry-color-text-strong);
155
- }
156
- ```
99
+ **If a DryUI component exists for it, use it.**
157
100
 
158
- See `rules/theming.md` for the full token system.
101
+ `DatePicker` not `<input type="date">`. `Select.Root` not `<select>`. `Dialog.Root` not `<dialog>`. `Separator` not `<hr>`. `Button` not `<button>`. DryUI components handle theming and accessibility automatically — native elements don't.
159
102
 
160
- ### Rule 7: Use DryUI components instead of native HTML equivalents
103
+ The test: search your markup for raw `<input`, `<select>`, `<dialog>`, `<button>`, `<hr>`, `<table>` — each should be a DryUI component instead.
161
104
 
162
- ```svelte
163
- <!-- Incorrect -->
164
- <input type="date" bind:value={date} />
165
- <select bind:value={choice}><option>...</option></select>
166
- <dialog>...</dialog>
167
-
168
- <!-- Correct -->
169
- <DatePicker.Root bind:value={date}>
170
- <DatePicker.Trigger>Pick a date</DatePicker.Trigger>
171
- <DatePicker.Content>
172
- <DatePicker.Calendar />
173
- </DatePicker.Content>
174
- </DatePicker.Root>
175
-
176
- <Select.Root bind:value={choice}>
177
- <Select.Trigger />
178
- <Select.Content>
179
- <Select.Item value="a">Option A</Select.Item>
180
- </Select.Content>
181
- </Select.Root>
182
-
183
- <Dialog.Root>
184
- <Dialog.Trigger>Open</Dialog.Trigger>
185
- <Dialog.Content>...</Dialog.Content>
186
- </Dialog.Root>
187
- ```
105
+ ## Quick Start
188
106
 
189
- DryUI provides themed, accessible replacements for native `<input type="date">`, `<select>`, `<dialog>`, and other HTML elements. Always prefer the DryUI component — it integrates with the theme system, provides consistent styling, and handles accessibility automatically. Look up the component with `info` before first use.
107
+ Run the install planner — it detects the project and returns a tailored step-by-step plan:
190
108
 
191
- ### Rule 8: Don't add decorative styling — output clean components
192
-
193
- When generating layouts or composing components, do NOT add decorative CSS such as gradients, box-shadows, rounded corners, colored left borders, background effects, or other visual embellishments. Output the components with their props and let the theme handle appearance.
194
-
195
- ```svelte
196
- <!-- Incorrect: decorative CSS baked in -->
197
- <div
198
- style="background: linear-gradient(135deg, #667eea, #764ba2); border-radius: 1rem; box-shadow: 0 4px 12px rgba(0,0,0,0.15);"
199
- >
200
- <Card.Root>...</Card.Root>
201
- </div>
202
-
203
- <!-- Incorrect: wrapper with decorative class -->
204
- <div class="fancy-card">
205
- <Card.Root>...</Card.Root>
206
- </div>
207
-
208
- <!-- Correct: just the component -->
209
- <Card.Root>
210
- <Card.Content>
211
- <Text>Clean output</Text>
212
- </Card.Content>
213
- </Card.Root>
214
-
215
- <style>
216
- .fancy-card {
217
- background: radial-gradient(circle at top right, rgba(99, 102, 241, 0.18), transparent);
218
- border-left: 3px solid var(--dry-color-stroke-brand);
219
- }
220
- </style>
109
+ ```
110
+ npx -y @dryui/cli install --toon
221
111
  ```
222
112
 
223
- The component library handles styling through CSS modules and `--dry-*` tokens. Adding decorative CSS on top creates visual inconsistency and fights the theme system. If the user wants custom visuals, they'll ask for them or apply them separately.
224
-
225
- ### Rule 9: Check composition before writing UI
226
-
227
- Before generating any DryUI layout or component composition, call `compose` with a description of what you're building. This ensures you use the correct components and avoid anti-patterns.
228
-
229
- Workflow:
230
-
231
- 1. Identify each distinct UI element you need (date input, image placeholder, progress stepper, etc.)
232
- 2. Call `compose` for each one — MCP: `compose({ query: "date input" })`, CLI: `bunx @dryui/cli compose "date input"`
233
- 3. Use the top-ranked component from the result
234
- 4. Follow the snippet patterns exactly
235
- 5. After writing, call `review` to validate
236
-
237
- Never skip this step. The compose tool exists because component selection mistakes (like using `<Input type="date">` instead of `DatePicker`) are invisible until someone sees the broken output.
113
+ Execute each `"pending"` step. Then verify: `npx -y @dryui/cli detect --toon` output should show `project: ready`.
238
114
 
239
- ### 10. Always create a thumbnail when adding a new component
115
+ ### Manual setup
240
116
 
241
- Run `bun run thumbnail:create <Name>` and customize the SVG markup in `packages/ui/src/thumbnail/<name>.svelte`. The MCP reviewer will flag components without thumbnails.
117
+ 1. `bun add @dryui/ui`
118
+ 2. Add `class="theme-auto"` to `<html>` in `src/app.html`
119
+ 3. In root layout (`src/routes/+layout.svelte`), import themes:
120
+ ```svelte
121
+ <script>
122
+ import '@dryui/ui/themes/default.css';
123
+ import '@dryui/ui/themes/dark.css';
124
+ </script>
125
+ ```
126
+ 4. Import `app.css` AFTER theme CSS if you have custom styles
242
127
 
243
- ## Tool Usage
128
+ ## Bindable Props — Common Confusion
244
129
 
245
- Use these tools to look up component APIs, discover components, plan project setup, and validate code. **Always look up a component before using it for the first time.**
130
+ Always verify with `info`, but these are the most common mistakes:
246
131
 
247
- ### MCP tools (preferred when available)
132
+ - `bind:value` (Input, Select, Tabs...) vs `bind:checked` (Checkbox, Switch) vs `bind:pressed` (Toggle) vs `bind:open` (Dialog, Popover, Drawer...)
133
+ - Select and Combobox support both `bind:value` and `bind:open`
134
+ - ColorPicker also exposes `bind:alpha`; Transfer uses `bind:sourceItems` / `bind:targetItems`
135
+ - Tour uses `bind:active`, not `bind:open`
248
136
 
249
- When the DryUI MCP server is installed, use the live inventory published in the docs AI surface pages. The tools group into four workflows:
137
+ ## Tools
250
138
 
251
- - Project setup and adoption planning: `detect_project`, `plan_install`, `plan_add`
252
- - Lookup and composition: `info`, `get`, `list`, `compose`
253
- - Validation and theme checks: `review`, `diagnose`
254
- - Repo audit: `doctor`, `lint`
139
+ Use these to look up APIs, discover components, plan setup, and validate code.
255
140
 
256
- Example calls:
141
+ ### MCP tools (preferred)
257
142
 
258
- ```ts
259
- detect_project({ cwd: '.' });
260
- plan_install({ cwd: '.' });
261
- plan_add({ name: 'Card', cwd: '.', subpath: true });
262
- info({ name: 'Card' });
263
- ```
143
+ | Workflow | Tools |
144
+ |----------|-------|
145
+ | Project setup | `detect_project`, `plan_install`, `plan_add` |
146
+ | Lookup & composition | `info`, `get`, `list`, `compose` |
147
+ | Validation | `review`, `diagnose` |
148
+ | Audit | `doctor`, `lint` |
264
149
 
265
- ### CLI fallback (when MCP is not installed)
150
+ ### CLI fallback
266
151
 
267
- If the MCP server is not available, use the CLI instead:
152
+ All commands support `--toon` for token-optimized agent output and `--full` to disable truncation.
268
153
 
269
154
  ```bash
270
- bunx @dryui/cli detect [path] # Detect DryUI project setup
271
- bunx @dryui/cli install [path] # Print the install plan
272
- bunx @dryui/cli add --project Card # Print a project-aware add plan
273
- bunx @dryui/cli info <component> # Look up component API
274
- bunx @dryui/cli get "<name>" # Retrieve composed output source
275
- bunx @dryui/cli list [--category] # Discover components
276
- bunx @dryui/cli review <file.svelte> # Validate Svelte component
277
- bunx @dryui/cli compose "date input" # Look up composition guidance
278
- bunx @dryui/cli diagnose <file.css> # Validate theme CSS
279
- bunx @dryui/cli doctor [path] # Audit workspace health
280
- bunx @dryui/cli lint [path] # Print deterministic workspace findings
155
+ bunx @dryui/cli info <component> --toon # Look up component API
156
+ bunx @dryui/cli compose "date input" --toon # Composition guidance
157
+ bunx @dryui/cli detect [path] --toon # Check project setup
158
+ bunx @dryui/cli install [path] --toon # Print install plan
159
+ bunx @dryui/cli review <file.svelte> --toon # Validate component
160
+ bunx @dryui/cli diagnose <file.css> --toon # Validate theme CSS
161
+ bunx @dryui/cli doctor [path] --toon # Audit workspace
162
+ bunx @dryui/cli lint [path] --toon # Deterministic findings
163
+ bunx @dryui/cli list --toon # List components
281
164
  ```
282
165
 
283
166
  Categories: action, input, form, layout, navigation, overlay, display, feedback, interaction, utility
284
167
 
285
- ## Rule File Pointers
168
+ ## Rule Files
286
169
 
287
- Read these files when you need deeper guidance on specific topics:
170
+ Read these when you need deeper guidance:
171
+
172
+ - **`rules/compound-components.md`** — Parts lists, component selection table, common mistakes
173
+ - **`rules/theming.md`** — Three-tier token system, dark mode, palette customization
174
+ - **`rules/composition.md`** — Form patterns, page layouts, composition recipes
175
+ - **`rules/accessibility.md`** — Field.Root, ARIA, focus management, pre-ship checklist
176
+ - **`rules/svelte.md`** — Runes, snippets, native browser APIs, styling rules
177
+ - **`rules/design.md`** — Minimal code, no premature abstraction, naming conventions
178
+ - **`rules/native-web-transitions.md`** — View Transition API, scroll animations, reduced-motion
179
+
180
+ ---
288
181
 
289
- - **`rules/compound-components.md`** -- Read when building with Dialog, Tabs, Accordion, Select, or any compound component. Contains parts lists and correct usage patterns.
290
- - **`rules/theming.md`** -- Read when setting up themes, customizing component styles, or fixing invisible/unstyled components.
291
- - **`rules/composition.md`** -- Read when building page layouts or forms. Contains layout patterns and form composition recipes.
292
- - **`rules/accessibility.md`** -- Read when handling form validation, focus management, ARIA attributes, or dialog patterns.
293
- - **`rules/svelte.md`** -- Read when writing Svelte 5 components. Covers rune usage, snippets, compound components, native browser APIs, and styling rules.
294
- - **`rules/design.md`** -- Read when writing or reviewing code. Enforces minimal, readable, correct code with no unnecessary abstractions.
295
- - **`rules/native-web-transitions.md`** -- Read when adding animations or transitions. Covers View Transition API, scroll-driven animations, reduced-motion handling, and progressive enhancement.
182
+ **These rules are working if:** every component traces to a lookup, diffs contain zero hardcoded colors, and the reviewer finds nothing.