svelte-headless-table and the Svelte 5 upgrade: your three options

svelte-headless-table has not shipped since October 2024 and declares svelte@^4. Here are the three real paths off it - the maintained fork, TanStack Table v9, or a rendered grid - and how to tell which one is yours.

If you are upgrading a Svelte app to 5 and svelte-headless-table is in your package.json, you have already hit the wall: the install warns about a peer conflict, and nobody has published a fix.

This post is the decision, not the sales pitch. We maintain SvGrid, which is one of the three options below - and for a good number of you it is the wrong one. The recommendation logic here is the same one we would give you in a GitHub thread.

What actually broke

Three facts, all checkable on the registry as of 26 August 2026:

• The last release of svelte-headless-table is 0.18.3, published 28 October 2024. That is 22 months of silence.
• It declares peerDependencies: { "svelte": "^4.0.0" }. Installing it next to Svelte 5 is a peer-range conflict - an ERESOLVE error on npm, a warning-then-breakage on pnpm.
• It still pulls roughly 64,000 downloads a month. This is not a dead library with three users. It is a widely used one that stopped moving.

One thing that is not broken, despite what a lot of migration posts (including, until today, one of our own docs pages) claim: Svelte 5 did not remove let: or slots. They are deprecated in favour of snippets and they still render. The official migration guide is explicit that they "continue to work". So your <Subscribe let:row> blocks are not a compile error.

The real friction is narrower and worth stating precisely, because it changes the decision:

1. The peer range is a hard install-time stop.
2. Slotted content cannot be passed to a component that renders with {@render ...}. The moment your codebase moves to snippets, the boundary between your runes components and headless-table's slot-based Subscribe starts to chafe.
3. Nothing is coming. Stores still work in Svelte 5, so this is not urgent in the way a breaking change would be - but you are building on a library whose maintainer has moved on.

That combination means: you have time, you are not in a crisis, and you should pick deliberately rather than reflexively rewriting.

Option 1: the maintained fork

@humanspeak/svelte-headless-table - v6.0.13, published 6 August 2026, peerDependencies: svelte ^5.30.0. Same API.

npm remove svelte-headless-table
npm i @humanspeak/svelte-headless-table

Then change your import paths. That is the migration.

Pick this if your table works and you only need it to install on Svelte 5. It is the cheapest path by a wide margin, and "cheapest path that works" is usually the correct engineering answer. Roughly 8,900 downloads a month say others reached the same conclusion.

The honest risk: it is a fork with one maintainer, so you are trading a stalled upstream for a smaller one. Check its commit activity before you commit to it - if that is not a trade you want to make, keep reading.

Option 2: TanStack Table v9

@tanstack/svelte-table - v9.1.2, published 9 August 2026, peerDependencies: svelte ^5.0.0. Around 194,000 downloads a month.

The category leader now has a first-party Svelte 5 adapter, so the old "TanStack has no Svelte 5 story" advice is out of date. If you like headless tables as a category - you want to own the markup, and the library should only own the row model - this is the largest, best-funded option in that category.

Pick this if you want to stay headless and you value ecosystem size. The concepts port over cleanly: column defs are column defs, and headless-table's plugins map onto TanStack's row models.

The honest cost: it is still headless-only. Every <table>, <thead>, and <tr> remains yours to write, style, virtualize, and make accessible. You are re-doing the markup work, not inheriting it. And v9 is a real migration - the API is not headless-table's.

Option 3: a grid that ships the renderer

This is us. SvGrid is Svelte 5 runes-native, MIT-licensed at the core, and it inverts the trade: instead of a row model plus your markup, you get a <SvGrid> component with virtualization, sticky headers, keyboard navigation, and ARIA already handled - with a headless core underneath at @svgrid/grid/core for when you do need the DOM.

npx @svgrid/migrate             # preview the changes
npx @svgrid/migrate src --write # apply them

The codemod translates column definitions and plugin config, deletes the Subscribe/Render scaffolding, and reports what it could not map instead of dropping it silently. Full detail in the migration guide.

Pick this if the markup is the part you are tired of. The clearest signal is if you have hand-rolled virtualization, a filter menu, or column resizing on top of headless-table and you resent maintaining them.

The honest cost: you give up DOM control at the component level, and some things genuinely do not come across - createRender(MyComponent) cell renderers become snippets, and custom plugins have no equivalent because there is no plugin system to port them into. That is a rewrite, not a migration. Advanced features (export, pivot, board and scheduler views) are a paid add-on; the grid itself is not.

Choosing

That last row is not a joke. A meaningful share of headless-table usage is a static list that never needed a table library, and the upgrade is a good moment to delete a dependency instead of replacing it.

The one thing not to do

Do not pin svelte@4 to avoid the decision. That trades a scoped afternoon of work now for a compounding one later, as the rest of your dependencies move to Svelte 5 and you fall off the upgrade path for every one of them. All three options above are live, maintained, and installable today - which is a better position than most stranded libraries leave their users in.

If you want the side-by-side on our option specifically, it is at SvGrid vs svelte-headless-table, including the cases where we tell you to use something else.