svelte.dev/packages

[benmccann]

This is based off the work from @PuruVJ in https://github.com/sveltejs/svelte.dev/tree/registry-2

I copied over only the svelte.dev/packages homepage without the search functionality or full registry (only the subset of packages we're displaying).

The scripts for updating the registry have also not been copied over. This is probably the main issue as stats such as latest version number, number of stars, number of downloads, etc. will be outdated. I'm not sure how we want to populate those and keep them updated

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Preview	Updated (UTC)
svelte-dev	Ready	Preview	Sep 23, 2025 2:48am

[jycouet]

Looks nice 🎉

I can do the 2-3 comments, just let me know.

[jycouet]

I didn't find alias used anywhere.

It was to replace the name on the ui card?
Maybe it could be "global" and not just for SV_ADD. (I saw that @inlang/paraglide-js is in multiple categories)

[benmccann]

It looks like it's to make it match the adder name

[benmccann]

I don't see any code in the registry-2 branch where that was ever used, so it looks like we'll have to implement that ourselves if we want it. I do think it makes sense for the sv add-ons row. I don't know that we'd want to rename @inlang/paraglide-js under "Third party services" because paraglide is really just referring to the sv add-on.

[jycouet]

We could do this:

Kind of nice things is that it can be also under like:

Thinking out loud... Maybe we can even get it of category SV ADD on top. And it can become a filter later?

---

Front front end is not my best talent!

[benmccann]

@Rich-Harris did most of the design and is pretty good at this stuff, so I'd be curious for his opinion on the addition of the Svelte icons and "npx sv add" commands and whether there might be a better way to accomplish this

[jycouet]

Maybe this is better

[benmccann]

I can do the 2-3 comments, just let me know.

I did what I could, but have to run. I'd definitely appreciate the help with the last comment if you have time and just getting this over the finish line in general. I'm finding less time for Svelte these days, but really wanted to try to help this get launched especially since it'd give us a nice place to highlight sv community add-ons.

[teemingc]

Some thoughts from using it on mobile:

• comparing it with https://astro.build/integrations/ I think our card design is a lot sleeker. Nice job!
• I tried tapping the cards to see what would happen only to realise I had to click the icons on the bottom right to learn more. Maybe clicking the package title/desc should link to the package website?
• There are a lot of categories and it can be a little overwhelming on mobile to scroll up and down to view them all. Would a sub navigation list at the top of the page help with this? Or are we waiting for the filter and search?
• Seeing sv add as a newcomer can be confusing. Is it worth explaining what it is or linking to the docs in a description?
• Should we link to this page from somewhere in the docs? Otherwise, it can be difficult to discover until you see it in the nav menu

[benmccann]

Having the card go to the website seems like a good idea
Agree "sv add" is a confusing title. At the very least it should be "sv add-ons" with that linked to the CLI docs
I think we should also have each card in the sv section go to the CLI docs for that particular add-on

[benmccann]

I don't have too much problem with the number of categories on mobile except that the page is hard to scroll. You can only scroll if you tap between categories and not on a card, which feels wrong to me

[jycouet]

I don't have too much problem with the number of categories on mobile except that the page is hard to scroll. You can only scroll if you tap between categories and not on a card, which feels wrong to me

Feels wrong to me too. Also on desktop, when you hover a card and scroll, nothing is happening.

Having the card go to the website seems like a good idea

Done with the title only

Agree "sv add" is a confusing title. At the very least it should be "sv add-ons" with that linked to the CLI docs
I think we should also have each card in the sv section go to the CLI docs for that particular add-on

Done.

---

Yes, sv add-ons section seems odd. What if we make sure that all add-ons are in at least one category? And we have it first on the list so that it's visible?

'prettier', -> Tooling
'eslint', -> Tooling
'vitest', -> Tooling
'playwright', -> Tooling
'tailwindcss', -> Tooling ? Component libraries ?
'vite-plugin-devtools-json', -> Tooling
'drizzle-orm', -> ?
'lucia', -> Auth ✅
'mdsvex', -> content ✅
'@inlang/paraglide-js', -> Third party services ✅
'storybook' -> Third party services ?

[Rich-Harris]

Brain dump:

• Notwithstanding the fact that we're only showing a curated subset here, I miss the search bar
• How curated is this, really? Do we need eleven different routers, one of which had 4 downloads last week?
• How do we ensure that the stats stay up to date? It would be easy enough to just update on deploy, but that would a) slow down deploys, and b) ensure that data was often stale
• Is it weekly downloads, or some other period? Would be good if the title (or better yet, a nicer tooltip) made that clear (and also formatted the numbers correctly — 57964 should either be 58K or 57,964)
• I feel like I'm missing context when I look at this page. What is an 'sv add-on'? Feels like maybe we need some descriptions
• Some of descriptions feel like AI slop. (Because they are!) In many cases they seem... fine when you glance at them, but the closer you look the more shitty it seems. Examples:
  • "A high-level API to automate web browsers, testing"
  • "Process Markdown for Svelte components"
  • "Add components to Svelte apps with Tailwind CSS"
  • "The headless components for Svelte"
  • "Provide Svelte UI components for AI SDK"
  • "Integrate documentation for SvelteKit"
  • "Free and open-source Tailwind CSS component library" (for felte, which doesn't export components and AFAICT has nothing to do with Tailwind, in a list of packages that are all free and open source)
  • actually, you know what, I have to stop or I'm going to end up including at least a third of the descriptions here. But you get the point. There's no consistency but lots of grammatical (and factual) errors, and they all feel like they've been asked to answer a subtly different question (like 'what does this library do?' versus 'what does this library enable its users to do?'). I get that the alternatives (relying on messy and inconsistent package.json descriptions, or manually writing them all) aren't ideal but my opposition to using AI here isn't ideological, it's because it fucking sucks
• why is svelte-chartjs in 'Individual components' rather than 'Component libraries' and/or 'Data Visualization'?
• why is 'Data Visualization' capitalized? Ditto '3D Rendering'
• I suspect this is my fault, but it's hella annoying that you can't scroll vertically if your mouse is hovering over a row
• the npx sv add ... blocks feel out of place. The red bar looks weird. Why does the link open a new tab? Would be nice if there was a copy-to-clipboard button (maybe this goes for everything, not just sv stuff, though it's hard to know which things need npm i vs npm i -D, and it also is very npm-centric, so then again maybe not)
• what is our strategy for handling the inevitable 'why is this thing included but not my thing?' bunfights?
• more generally, what are our criteria for inclusion? like, we have paraglide which is basically dead at this point, but no alternatives like wuchale. Superforms is cool, but IIUC it's not going to be updated to use state instead of stores, which means it's going to stop working at some point, which means we probably shouldn't be actively recommending it to people. (Same likely goes for other libraries, this is just one example I came across. sswr — "Fetch data with SWR strategy for Svelte, improving performance" is another fine example of AI slop — is another.) In the meantime, remote functions arguably make existing form libraries obsolete

So... idk. This doesn't feel like a curated page of actively-maintained, highly-recommended packages. It feels like a random assortment with a few gems but a lot of dross. I don't really know when I would use this over Google. I think that if we're going to curate, we need to curate much more aggressively.

[benmccann]

what are our criteria for inclusion?

Basically ambassadors and maintainers nominate things that are good or not and vote on them to add or remove things. We should definitely have everyone do a pass on this once we've got the rest settled. The content hasn't been thoroughly vetted. The router category hadn't been reviewed at all, so I just cleaned that up a bunch. Reasonable people will disagree on many of the others, but I think they're at least defensible even if not perfect. wuchale looks brand new and not very used, so not surprised it isn't listed here. paraglide even if only infrequently developed is still one of the better libraries out there. For sswr, remote functions only work for sveltekit and non-sveltekit users may still want options. superforms is still being worked on even if a bit behind.; From the superforms repo:

"With both the Runes update and remote functions, I'm leaning towards a full rewrite for v3"