Understand component requirements
The declarations every published component makes about its runtime, integration level, dependencies, services, files and release state.
Start with the runtime, packages, services and limitations to decide whether a component fits your project. The tables below explain the structured metadata behind those requirements. The website, the public API and the MCP server all read the same generated manifests, so a declaration means the same thing wherever you see it.
Identity and versions #
| Field | Meaning |
|---|---|
id |
Stable identifier such as cmp_pricing_grid_001. It never changes, even if the slug does. |
slug |
The public URL name. Previous slugs are kept as aliases so old links keep working. |
version |
An exact MAJOR.MINOR.PATCH release. Retrieval always uses an exact version, never "latest". |
status |
published, deprecated or withdrawn. Drafts never appear in public output. |
A deprecated release remains retrievable while it is the component's current release, and carries a reason, a date and, where there is one, a replacement component and migration note. Older releases are not yet retained once a newer release is published. A withdrawn release can no longer be retrieved; requests for it return the WITHDRAWN error with a public reason and, when available, a replacement.
Compatibility #
| Field | Values |
|---|---|
runtime |
Determines whether SvelteKit is required. svelte works in any Svelte 5 project. sveltekit needs SvelteKit, for example because it imports $app/ or @sveltejs/. |
svelteMajor |
Always 5. |
svelteKitMajor |
The SvelteKit major the component targets (2), or null. Required for sveltekit components and may also be set on portable svelte components; it does not make SvelteKit a requirement. |
tailwindMajor |
Always 4. |
ssr |
supported renders on the server. client-only must only render in the browser. |
requiresClientJs |
Whether the component needs JavaScript in the browser to be usable. |
Kind and integration level #
The kind describes what the component is: a section, a control, a composition of other parts, or an integration-recipe.
The integration level describes how much your project has to supply:
presentational: renders markup from props. Nothing to connect.local-interaction: manages its own client-side state, such as a disclosure or a carousel, without talking to a server.service-required: needs a service you provide, such as form delivery or payments. The component declares what it does not do.kit-recipe: a SvelteKit integration pattern delivered as helper and snippet files, with instructions for the route or server code you create in your own project. See SvelteKit recipes.
Dependencies and services #
dependencies lists third-party packages with the supported semver range, the purpose of each package, and the testedVersion resolved when the release was built. Svelte and Tailwind themselves, and SvelteKit (including @sveltejs/kit imports) for sveltekit components, are prerequisites, not dependencies.
services lists external services a component expects. Each service entry has a category, a description, the configuration you must provide and a list of responsibilities the component does not implement. Read that list carefully: a contact form that renders fields does not deliver email for you.
These declarations drive the dependency filter, which has three values: none (no third-party runtime package and no external service), third-party and external-service. More in dependencies and assets.
Files #
Each release exports an explicit allowlist of at most 50 files. Every file has a role: entry, component, helper, types, style or asset. Paths are relative, and a suggestedDirectory tells you where the component expects to live. Keep the relative paths intact when you copy files.
Usage, props and customization #
Each release documents a usage summary, an example, required props and known limitations, plus a prop table with types, defaults and descriptions. Customization lists the palette tokens you can override and a short guide. See customization.
Preview trust boundary #
Previews run the component's own code, which has been reviewed in the catalogue repository, inside a same-origin iframe. The iframe isolates layout and styles from the surrounding page and blocks navigation and form submission, but it is not a security boundary against hostile code. Accepting user-submitted components would require serving previews from a separate origin.
Appearance #
modes lists the supported appearance modes (light, dark). When dark mode is supported, modeSelection describes how your project selects it for that component. Do not assume every component follows the same mechanism.
Accessibility, license and provenance #
Every release includes accessibility notes and known limitations (accessibility), a source license and per-asset licenses (license), and a provenance record stating whether the component is original or adapted.