# Central Design System (CDS 4) — full documentation
> Version: 4.0.0-alpha.13
> Everything at once: guides, tokens and themes, components with examples and the API contract, CDS 3 migration.
> Generated automatically (`bun run generate:meta` → `bun run generate:llms`). Do not edit manually.
---
## Setup
```ts
import { createApp } from 'vue';
import '@central-design-system/components/styles';
import { createCds, components, directives } from '@central-design-system/components';
import App from './App.vue';
const cds = createCds({ components, directives });
createApp(App).use(cds).mount('#app');
```
Usage: `Click me`.
This is full registration: the `components` namespace import and the `styles`
aggregate keep the entire library in the bundle. It suits places where the set of
components is not known upfront (admin panels, sandboxes, documentation). In product
applications register components individually — `createCds({ components: { CdsButton } })`
plus the base style layer `@central-design-system/components/styles/common.css`;
see the "Tree-shaking" guide for details.
## Conventions
- **Uniform props.** `size`, `color` / `bgColor`, `appearance`, `disabled`, `loading`,
`width` / `height` behave the same across all components (shared composable factories).
- **Tokens, not raw values.** Colors are set via the `color` prop, not arbitrary CSS.
- **Atomic Design.** Complex UI is assembled from atoms (e.g. a form:
`CdsField` + `CdsLabel` + `CdsDescription` + `CdsMessages` + `CdsInput`).
- The full CDS 3 → CDS 4 migration guide lives in `MIGRATION.md`.
---
# Setup and themes
## Installation
```bash
npm install @central-design-system/components
```
## Wiring it into the app
```ts
import { createApp } from 'vue';
import '@central-design-system/components/styles';
import { createCds, components, directives } from '@central-design-system/components';
import App from './App.vue';
const cds = createCds({ components, directives });
createApp(App).use(cds).mount('#app');
```
After that every component is available globally: `Click me`.
This is the full registration — it pulls in the entire library. For production
apps register components individually, see the Tree-shaking guide.
## Style entry points
| Import | What it provides |
| --- | --- |
| `@central-design-system/components/styles` | Aggregate: CSS of every component (~556 KB). Quick start, tree-shaking disabled |
| `@central-design-system/components/styles/common.css` | Base layer (~9 KB): layers, reset, fonts, typography, grid |
| `@central-design-system/components/styles/core` | Only layers, fonts and reset — no typography |
| `@central-design-system/components/styles/utilities` | Utility classes |
| `@central-design-system/components/styles/tailwind` | Tailwind CSS integration layer |
| `@central-design-system/components/styles/legacy` | Legacy utilities for migrating from CDS 3 |
With per-component registration you only include the base layer
`styles/common.css` — each component ships its own CSS alongside the
component itself.
Tailwind CSS v4 integration (installation, layers, utilities built on CDS
tokens) is covered in the Tailwind CSS + CDS guide.
## Themes
The theme is set at initialization via `createCds`:
```ts
const cds = createCds({
components,
directives,
theme: { defaultTheme: 'b2bLight' }
});
```
Built-in themes: `cdsLight` (default), `cdsDark`, `b2bLight`, `b2bDark`,
`promoLight`, `promoDark`. The values of every color token in each theme
are listed in ../tokens/themes.md.
Custom themes, runtime theme switching and disabling theming are covered in
the Theming guide.
## Icons
The Phosphor iconpack is active by default and needs no setup: its CSS ships
with the package. Other packs are available too (`cds`, `lucide`,
`materialSymbols`, `remix`, `tabler`):
```ts
import { createCds, iconsets } from '@central-design-system/components';
createCds({
icons: {
defaultSet: 'remix',
sets: { remix: iconsets.remix.icons },
aliases: iconsets.remix.aliases
}
});
```
The `@central-design-system/icons` package (CDS 3) is deprecated, see the
migration guide.
---
# CDS 4 conventions
The golden rule: **the source of truth is the component's `api.md`**
(`references/components//api.md`). Do not invent props, events or
slots — if they are not in api.md, they do not exist on the component.
## Shared props
The props below come from shared composable factories and behave identically
in every component that has them:
| Prop | Semantics |
| --- | --- |
| `size` | Size: `xs` / `sm` / `md` / `lg` / `xl` or a number |
| `appearance` | Appearance (visual variant); the set of values is component-specific — check the type in api.md |
| `color` / `bgColor` | Content / background color as a **theme token**, not a CSS value |
| `disabled` | Disabled state |
| `loading` | Loading state |
| `width` / `height` | Dimensions (number → px, or a CSS value as a string) |
## Tokens, not raw values
- Set colors via the `color` prop / theme tokens (`--cds-color-*`), never
arbitrary CSS (`#fff`, `red`). Theme tokens are listed in ../tokens/themes.md.
- Spacing, radii and other values in custom SCSS go through the global
`--cds-*` variables, never hardcoded.
## Atomic Design
Complex UI is composed from atoms. Example — a form: the ready-made
`CdsTextInput` "molecule" is internally built as `CdsField` + `CdsLabel` +
`CdsDescription` + `CdsMessages` + `CdsInput`, and the same atoms are
available for building your own fields. See the Forms guide
for details.
## Defaults
Prop defaults can be set centrally:
- globally — via the `defaults` option in `createCds({ defaults: { CdsButton: { size: 'lg' } } })`;
- for a subtree — with the `CdsDefaultsProvider` component
(api).
## Deprecated APIs
Props/components marked `_(deprecated)_` in api.md still work but will be
removed. In the dev console they emit a warning prefixed `[CDS UPGRADE]`.
When migrating legacy code, see the migration guide.
---
# Forms with CDS 4
## Ready-made controls
For typical forms use the ready-made "molecules" (each has its own `api.md`
and `examples.md` in `references/components/`):
| Control | Purpose |
| --- | --- |
| CdsTextInput | Text field with label / description / messages |
| CdsSelect | Dropdown (single / multiple) |
| CdsAutocomplete | Selection with search over the list |
| CdsCombobox | Selection that also accepts free-form input |
| CdsCheckbox | Checkbox |
| CdsRadioGroup | Radio button group |
| CdsToggle | Toggle |
| CdsDatePicker / CdsTimePicker | Date / time |
## CdsForm: aggregation and validation
`CdsForm` groups fields, aggregates their validation (`v-model` — form
validity) and exposes `validate` / `reset` / `resetValidation` methods via
slot props and the exposed API. Validation rules are set on the fields with
the `rules` prop (an array of functions `value → true | 'error text'`).
A verified example (from Storybook):
```html
ClearSubmit
```
```ts
const valid = ref(false);
const name = ref('');
const email = ref('');
const rules = {
name: [
(value: string) => !!value || 'Must not be empty',
(value: string) => value.length <= 10 || 'No more than 10 characters'
],
email: [
(value: string) => !!value || 'Must not be empty',
(value: string) => /.+@.+\..+/.test(value) || 'Invalid format'
]
};
```
Useful modes (full list in api.md):
- `first-fail` — validation stops at the first invalid field;
- `disabled` / `readonly` on the form propagate to every nested field.
CdsForm also works with external validators (vuelidate, vee-validate) — see
examples.md.
## Building your own field from atoms
When no ready-made molecule fits, assemble the field from atoms:
| Atom | Role |
| --- | --- |
| CdsField | Field wrapper: wires up label/control/messages, states |
| CdsLabel | Field label |
| CdsDescription | Supporting description |
| CdsMessages | Error messages / hints |
| CdsInput | Bare input control |
Before assembling, open the `api.md` of every atom — take the set of props
and slots only from there.
---
# CDS 3 → CDS 4 migration (digest)
This is a short digest. **The full version with Before/After for every
change is `MIGRATION.md` at the root of the
`@central-design-system/components` npm package.**
## Severity legend
| Marker | Meaning |
| --- | --- |
| ⚠️ **BREAKING** | Breaks existing code — action required |
| 🔁 **RENAMED** | Rename — mechanical search & replace |
| 🟠 **DEPRECATED** | Works in 4.x, will be removed in 5.x |
| ✨ **NEW** | New capability, nothing breaks |
## Quick checklist
- [ ] Replace the CSS import: `@central-design-system/components/dist/cds.css` →
`@central-design-system/components/styles` (⚠️ breaking).
- [ ] If you use `@central-design-system/icons` — the package is 🟠 deprecated;
switch to iconpacks via `createCds({ icons })` (see setup.md).
- [ ] Go through the component rename index below.
- [ ] Run the build and check the dev console: `[CDS UPGRADE]` warnings
point at deprecated props.
## Key breaking changes
- ⚠️ **CSS import path** — `dist/cds.css` is no longer a public entry point;
import `@central-design-system/components/styles` instead.
- ⚠️ **Legacy reset is off by default** — the global reset from CDS 3 is now
opt-in: `@use '@central-design-system/components/styles' with ($legacy-reset: true);`.
- ⚠️ **CSS architecture on ITCSS + CSS Layers** — the cascade is driven by
native `@layer`; global overrides of CDS styles without `!important` may
now resolve differently.
## Component rename and removal index
| CDS 3 | CDS 4 |
| --- | --- |
| `CdsDropdown` | 🔁 `CdsSelect` (the native `