Why we publish components as source, not packages

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 API can make some of those changes awkward. 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 adapt.

What "source-first" means here#

When you take a component, you receive files. There is no runtime package from us, and no automatic changes to your copied files when we publish a new release. Declared third-party packages still need maintenance. You can rename props, delete a column, or rewrite the markup, without waiting for a new configuration option. Keep the applicable source and asset licenses with your copy.

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. You still need to understand and maintain what you add. Check the license status before adopting source.

Declarations before downloads#

Every release carries a structured contract that you can read before you take anything:

• Runtime. Plain svelte, or sveltekit when it needs the framework.
• Integration level. presentational, local-interaction, service-required or kit-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 can integrate a component more reliably when its requirements are explicit. 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.

The setup guides record documentation checks and, where available, command confirmation. End-to-end client testing has not been published. 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, with its requirements and limits already documented.