Why we publish components as source, not packages
Copying a component's source into your project trades automatic upgrades for ownership. Here is why we think that is the right trade for website sections, and how we make it safe.
- source-first
- svelte
- sveltekit
- agents
Most UI libraries arrive as a package. You install it, import from it, and configure it through whatever props and theme options its authors anticipated. That works well for primitives with stable APIs. It works much less well for the parts of a website that make it look like your website: the hero, the pricing table, the feature grid, the footer.
Those sections are where a design gets edited. A package turns every edit into a fight with an abstraction. So this catalogue takes the other route: every component is Svelte 5 source styled with Tailwind CSS 4 that you copy into your project and then own.
What "source-first" means here #
When you take a component, you receive files. There is no runtime package from us, nothing to keep in sync, and nothing that changes underneath you when we publish a new release. You can rename props, delete a column, or rewrite the markup, and it is still just your code.
That freedom has a cost: you lose automatic upgrades. We think that is an honest trade for website sections, but only if the source you start from is well described. Copying code you do not understand is not ownership.
Declarations before downloads #
Every release carries a structured contract that you can read before you take anything:
- Runtime. Plain
svelte, orsveltekitwhen it needs the framework. - Integration level.
presentational,local-interaction,service-requiredorkit-recipe. - Dependencies. Each third-party package with a supported range, a purpose and, when available, the exact version resolved when the release was built.
- Services. What an external service must do, including an explicit list of what the component does not implement.
- Files. An allowlist of exported files, each with a role, a size and a SHA-256 hash.
A contact form section that declares "does not deliver email" is more useful than one that quietly posts to nowhere. The component contract documents each field.
Exact versions, every time #
Source-first only works if "the component" means exactly one set of bytes. Releases are exact versions, each variant is exported once into an artifact, and the artifact is identified by a digest computed from its receipt, so its URLs are content-addressed. Asking for a version that does not exist is an error; you never silently get the latest release instead.
That makes a copied component traceable. Keep the bundle.json receipt next to the files and you can always tell which release your copy started from. That matters because the site currently serves only each component's current release; older releases are not yet retained, so your receipt is the durable record. The distribution format explains how the digest is computed.
Built for agents as well as people #
Coding agents are good at integrating code and bad at guessing what a component needs. The same catalogue data is available through the MCP server, so an agent can search with hard constraints, inspect the contract, pin a version, retrieve every file and then run your project's checks. The server returns information and download locations; it never writes to your project.
We have not published client compatibility testing yet, and we will not list a client as supported until we have. The agent workflow describes the sequence we recommend in the meantime.
Where to start #
Read getting started, check your Tailwind setup, and pick something small first. The goal is that the first component you copy feels like code you could have written, only already reviewed and documented.