shadcn-svelte-extras publishes the components shadcn-svelte does not have

A registry of the components that were missing

The README puts the pitch in one line: turn key shadcn-svelte components to help you finish your app. The site is shadcn-svelte-extras.com, the licence is MIT, the primary language is Svelte, and the repository topics are components, shadcn and svelte.

The framing matters because this is not another component library. shadcn-svelte is a set of components you copy into your project, and this project sits next to it as a registry of the ones that are not there yet. The README's component table is a catalogue of exactly that kind of gap fill: a Chat component for creating live chats, an Emoji Picker described as a composable emoji picker component, a File Drop Zone, an Image Cropper for uploading and resizing images, a Terminal described as an implementation of the MacOS terminal and useful for showcasing a command line interface, a Tree View for file trees, a Window component, and a PM Command component for package manager commands.

The releases show an active line: v7.2.1 from 2026-10-15, v7.2.0 from 2026-08-11 and v7.1.4 from 2026-08-10, with the last push on 2026-10-22.

The catalogue skews towards forms and inputs

Reading the table in order shows where the demand is, and it is mostly inputs and the awkward interactive widgets.

There is an extended Button, a simple Link, a responsive Modal dialog, a Password input, a Phone Input for phone numbers, an IPv4Address Input described as having all the behavior you would expect, a Field Set, a Tags Input, a Star Rating, a Rename component, a Snippet, a Code component, a Copy Button for clipboard text, an NLP Date Input with suggestions, and a Light Switch for changing the theme along with a Theme Selector.

The rest are bigger surfaces. Chat, Image Cropper, File Drop Zone, Tree View, Window, Terminal and PM Command.

The pattern is telling. The plain building blocks, a button, a link, a dialog, a table cell, are the ones shadcn-svelte already provides and that you would not look for in an extras registry. What lands here is the work that a design system rarely covers, either because it is product specific, such as a terminal window or a file tree, or because it needs a real dependency to do properly, such as an emoji picker or a password strength meter.

The README also says and more, so the list is only part of the inventory.

Installation is jsrepo, and it copies source into your app

The documented install path is jsrepo, and there are two steps.

Initialize the registry:

jsrepo init @ieedan/shadcn-svelte-extras

Then install components, either as a list or one at a time:

jsrepo add # list

jsrepo add button # single

The two forms in the second block are the two modes: `jsrepo add` with no argument lists what is available, and naming a component installs that one. There is no instruction to add a dependency for the whole set.

That is the design, and it is inherited from the shadcn approach. The component source is written into your repository, so you own it, you can edit it, and it becomes part of your codebase rather than a version you pin. The trade is the usual one: you get the code and the flexibility, and you give up automatic updates and inherit the maintenance of whatever you copied.

For a component like the Image Cropper or the Emoji Picker, that is often the right trade, because the code is a starting point that you will adjust anyway. For the small ones, a button, a link, a dialog, copying them from a registry is more ceremony than writing the twenty lines yourself.

The registry is built from this repository

The package manifest explains how the components are published, and it is not a conventional package publish.

The scripts are the interesting part. `registry:build` runs `jsrepo build`, `registry:dev` runs `jsrepo build --watch`, and `ci:release` runs `jsrepo publish && changeset tag`. The release pipeline therefore builds a component registry and then publishes it, and changesets handle the versioning, so a release tag follows a change to the registry rather than to a library on npm.

The development script shows that this repository is three things at once. `dev` runs three processes concurrently, named registry, app and content, and the three are `pnpm registry:dev`, `pnpm dev:app` and `pnpm dev:content`. The app is `vite dev`, and the content is `velite dev --watch`.

So the repository contains a component registry, the documentation site that consumes it, and a content pipeline, and they are built together. The `components.json` file at the root and the `jsrepo.config.ts` describe the registry, and `.jsrepo/` is its directory.

The docs site is a content pipeline of its own

The content side of the repository has its own toolchain, and it is worth naming because it explains the quality of the documentation you get.

Velite is the content build tool, with `velite.config.ts` at the root and a `content/` directory of the source content. The `mdsx.config.js` file configures MDX processing, and the Shiki packages, `@shikijs/themes` and `@shikijs/langs`, provide the syntax highlighting for the code examples. The `rules/` directory holds the writing rules, `messages/` holds the translatable strings, and `project.inlang/` is the inlang project directory.

Internationalisation is handled by Paraglide JS, with the `generate-i18n` script running `paraglide-js compile --project ./project.inlang --outdir ./src/lib/paraglide`. The compiled output lands inside the library itself, in `src/lib/paraglide`, which means the translations ship with the components rather than with the docs site.

For a component registry, that is a sensible investment, because the same registry serves the documentation site and the code that users copy.

What the components are built on

The development dependencies in the package manifest describe the implementation, and several of them map directly onto a specific component.

`@sveltejs/kit` with `@sveltejs/vite-plugin-svelte` and `@sveltejs/adapter-cloudflare` is the application framework, so the registry and its site are a SvelteKit app. `@tailwindcss/vite` is Tailwind version 4, which is consistent with a shadcn-svelte ecosystem built on Tailwind. `@lucide/svelte` provides the icons.

Then the component specific ones. `@emoji-mart/data` is the emoji dataset behind the Emoji Picker. `@zxcvbn-ts/core` with `@zxcvbn-ts/language-common` and `@zxcvbn-ts/language-en` is password strength estimation, which is what the Password component must be using. `@internationalized/date` is the date library that a natural language date input has to sit on. `@tanstack/table-core` is included as a dependency, most plausibly for the Tree View. The fonts are `@fontsource-variable` packages for Geist, Geist Mono and Inter, and `@lukulent/svelte-umami` is an analytics component.

One detail worth noting for anyone copying a component: the `package.json` is marked `"type": "module"` and the package manager is pinned at `[email protected]`, and the version of the package itself is 7.2.1, matching the latest tag. The npm package is private in spirit even though it is published, since the consumer path is the registry.

Where the copied-code model bites

The limitation is not a missing feature, it is the delivery model, and it is worth being blunt about it.

When you install a component from a registry, the code becomes yours. There is no version constraint to bump, so when the registry publishes a fix, your copy does not change. Two teams using the same component can therefore be on different versions of it, and a bug fixed upstream in the registry stays unfixed in your application until someone notices and updates by hand. The changelog and the tags are there, but nothing pushes them to you.

The second cost is dependency weight, and it arrives per component rather than per project. A user who copies only the Star Rating gets one library. A user who copies the Emoji Picker, the Password input and the NLP Date Input gets the emoji dataset, the password strength packages and the internationalized date library, each of which has to be compatible with your Svelte and Tailwind versions.

The third is that the catalogue is finite and opinionated. Twenty four components is a good haul for the gaps in a design system, but it is not a system, and the components follow one visual language. If your product needs something outside that language, you will be editing the source you just copied, which is where the shadcn approach stops helping.

The sensible pattern is to treat it as a source of starting points. Copy the component that saves you a week, adjust it to your conventions, and own it from then on.

Editorial conclusion

Adopt shadcn-svelte-extras when you are building a Svelte app on shadcn-svelte and need one of the components it does not ship, and when you are comfortable copying component source into your own repository. Do not adopt it as a package you can upgrade, because the code lands in your project and stays there, so registry updates do not reach you. Verify first that the component you need is listed, that the dependencies it pulls in match your stack, and that the version you copy matches the release you read, with v7.2.1 published on 2026-10-15 and the last push on 2026-10-22.

Frequently asked questions

Official sources

1. ieedan/shadcn-svelte-extras on GitHub
2. License: MIT
3. Project website
4. README
5. Releases