Deprecations
The live list of what is going away, what replaces it, when it was deprecated and when it will be removed.
The list
Nothing has been deprecated, because nothing has been released. This page is not a placeholder for that reason. It is the address the deprecation process points at from day one, so that the first deprecation has somewhere to appear and does not arrive as a surprise in a changelog entry.
No script produces it yet. scripts/build-registry.mts reads
registry/catalogue.ts and emits /r, and it has no deprecation projection, so
nothing here fills itself in.
Nothing on this site types a measured number by hand, so an ungenerated table shows this rather than an example.
When it has rows, each carries: the deprecated thing, its replacement, the
version that deprecated it, the version that will remove it, and one sentence
saying why. Today a row is written by hand, in the same change that sets the
catalogue row to deprecated: a pull request that does one without the other is
incomplete, and reviewing for it is the only thing standing in for a generator.
Projecting the rows out of the catalogue is the better answer and is not built.
What being on this list means
It still works. A deprecated component, prop or token keeps working for at least one minor release before 1.0 and for a full major after it. Something that stops working is a removal, and a removal that called itself a deprecation is a broken promise, not a policy detail.
It has a replacement, or an explanation. Most rows name what to use instead. Where there is no replacement, it is because the thing should never have existed. The row says so and links to the reasoning, which is usually a decision record.
It is not recommended for anything new. If you are starting work today, treat a deprecated row as absent.
How to find out early
Read Versioning policy for the full process, and the changelog for what actually happened in each release. If a deprecation needs more than a paragraph to migrate through, it gets a written guide rather than a longer changelog entry, and Versioning policy says which kinds of change earn one.
The other half of this is knowing which version your copy came from, because that
is what tells you whether a deprecation applies to code already sitting in your
repository. Nothing in the file answers that, so the answer has to come from
your own version control: commit the files shadcn add writes, in their own
commit, so a later --diff has something to compare against.
Last read through against the system on 2026-09-02. Due for review every 6 months; expiry is reported by pnpm run check:freshness.