shadcn-ui/taxonomy: an archived Next.js 13 experiment that tells you it is archived

The README opens by saying the project is officially archived

The first thing in the README is a note, and it is unambiguous. The project has been officially archived and will no longer receive updates. In place of a roadmap for the future, there is a pointer to the Templates directory for Next.js starters, and three reasons in a list: the code does not reflect current best practices, it may contain deprecated APIs or patterns, and it is not recommended for use in production environments.

The stated reason is chronological. The author started the project when the Next.js App Router was in public preview, and because the framework has since stabilized and undergone significant architectural changes, the code drifted. So the gap between this tree and current practice is not sloppiness, it is age. The repository is flagged as not archived, but the project describes itself as archived, and the last push was 2026-04-20 with no GitHub releases at all, so there is no version to pin to. Read it as a record of one approach rather than as a dependency.

Three known issues are struck through and one is left open in the framework

The Known Issues section uses strikethrough as its status marker, which makes it unusually easy to read. Three entries are struck through and therefore treated as resolved: GitHub authentication, with a note to use email instead; a Prisma error, ENOENT, no such file or directory for /var/task/.next/server/chunks/schema.prisma, linked to a Prisma issue; and a Next.js 13 problem where client side navigation does not update head, linked to a Next.js issue.

One entry is not struck through: cannot use opengraph-image.tsx inside catch-all routes, linked to another Next.js issue. That is the only item the project still lists as not working, and it is a framework level problem. No amount of work inside the application closes it, which is the clearest illustration of why the archive notice sits at the top.

For anyone reading the list to judge the code, the signal is mixed: application level bugs got fixed, and a framework bug remains.

pnpm install runs prisma generate, and pnpm dev starts two processes

The package scripts describe the shape of the development loop more precisely than the feature list does:

"dev": "concurrently \"contentlayer dev\" \"next dev\"",
"build": "contentlayer build && next build",
"turbo": "next dev --turbo",
"postinstall": "prisma generate"

Three things follow. Installing is not only fetching packages, because postinstall runs prisma generate, so the database client is built during install and an install in an environment without the Prisma schema is not a clean no-op. Building is a two stage pipeline with contentlayer build before next build, meaning the MDX content is compiled to data before the framework build reads it, and a content error surfaces in the first stage. Running is two long-lived processes orchestrated by concurrently, contentlayer in watch mode and next dev, so the terminal carries interleaved logs from both.

There is also a turbo script, next dev with the turbo flag, which is the one obvious remnant of the public preview era, and a package version of 0.2.0 with the package marked private.

A local run expects credentials for four services before anything works

The environment file is the honest inventory of what the application talks to. It is grouped into sections, and the groups are: App, with NEXT_PUBLIC_APP_URL; Authentication for NextAuth.js, with NEXTAUTH_URL, NEXTAUTH_SECRET, GITHUB_CLIENT_ID, GITHUB_CLIENT_SECRET and GITHUB_ACCESS_TOKEN; Database, MySQL on PlanetScale, with a single DATABASE_URL that defaults to "mysql://root:root@localhost:3306/taxonomy?schema=public"; Email through Postmark, with SMTP_FROM, POSTMARK_API_TOKEN, POSTMARK_SIGN_IN_TEMPLATE and POSTMARK_ACTIVATION_TEMPLATE; and Subscriptions through Stripe, with STRIPE_API_KEY, STRIPE_WEBHOOK_SECRET and STRIPE_PRO_MONTHLY_PLAN_ID.

Four external providers, and the local run is three commands: `pnpm install`, then `cp .env.example .env.local`, then `pnpm dev`. Copying the example file gives you mostly empty values, and the README says to update the variables.

The Postmark group is the one to read twice. Two of its variables are template identifiers, one for sign-in and one for activation, which means the email flows are template driven.

Both app/ and pages/ sit in the tree, so two routers coexist

The experiment was the app router, and the feature list names the new /app dir first. The repository root, however, carries both directories: app/ and pages/, alongside middleware.ts, contentlayer.config.js, prisma/, config/, content/, lib/, types/, styles/, hooks/, components/ and assets/. A project that has fully moved to the app router would not normally keep a pages directory, so its presence is the clearest trace of the transition the author was testing.

The practical consequence is for a reader. A route can be owned by either directory, and the router decides which one wins, so when you are tracing why a URL renders a particular way you have to know that both trees are in play. The same applies to the dependency list, which installs individual Radix packages rather than a wrapper, with entries for accordion, alert-dialog, aspect-ratio, avatar, checkbox, collapsible, context-menu, dialog, dropdown-menu, hover-card, label, menubar, navigation-menu, popover, progress, radio-group, scroll-area, select, separator and slider, plus a set of Editor.js packages for code, embed, header, inline-code, link, list, paragraph and table.

So the components directory is assembled from about thirty headless packages rather than from a component library you install once.

Next.js only was a deliberate constraint, stated in one sentence

There is a section headed Why not tRPC, Turborepo or X?, and the answer is three sentences long. I might add this later. For now, I want to see how far we can get using Next.js only. If you have some suggestions, feel free to create an issue.

That constraint explains the rest of the tree. There is no tRPC layer generating typed API routes, so the route handlers and the server components talk to the database directly through Prisma. There is no monorepo task runner, so the only orchestration in package.json is concurrently for the two dev processes, and the content pipeline is Contentlayer rather than part of the framework build. The data fetching, caching and mutation entries in the feature list are all framework features being exercised rather than a data layer being assembled.

The consequence for reuse is specific. This tree demonstrates the app router, not an application architecture. If you lift the data access into a larger product with more than one service, the missing tRPC layer is not a gap you inherit, it is one you now have to build, and the section above says as much by listing it as a possible later addition.

Every roadmap item is struck through, so the feature list is the finished scope

The roadmap has six entries and all six are checked off, five of them also struck through, the same marker used for the fixed known issues: MDX support for basic pages, marketing pages, subscriptions using Stripe, responsive styles, an OG image for the blog using @vercel/og, and dark mode. Nothing is left open, which means the feature list is the delivered scope rather than an intention.

That list is worth reading as an architecture summary, since each item names a library: authentication through NextAuth.js with a Prisma adapter, an ORM in Prisma, a database on PlanetScale, UI components built from Radix UI, documentation and blog content in MDX with Contentlayer, subscriptions through Stripe, styling with Tailwind CSS, validation with Zod, and the whole thing in TypeScript. Routing, layouts, nested layouts and layout groups, data fetching, caching and mutation, loading UI, route handlers, metadata files, server and client components, API routes and middlewares are the framework features it demonstrates.

So the repository is best understood as a finished argument about one stack, frozen at a point in time, and archived for exactly that reason. The MIT license still applies, so the code is yours to take; what you should not take is the expectation that it is current.

Editorial conclusion

Use shadcn-ui/taxonomy as a reference for how the Next.js app router was used when it was new, and as a working example of a specific stack: NextAuth, Prisma, PlanetScale, Contentlayer, Stripe, Radix UI, Tailwind and Zod wired together. Do not adopt it as a starting point for a production app, because the README says outright that the code does not reflect current best practices, may contain deprecated APIs, and is not recommended for production environments. Check three things before you copy anything: the state of the tree, since the last push was 2026-04-20 and there are no GitHub releases to pin to; the external services, because a local run wants GitHub credentials, a MySQL URL, Postmark templates and Stripe keys before authentication, email or billing work; and the one live known issue, which is that opengraph-image.tsx cannot be used inside catch-all routes, a Next.js bug rather than an application bug. If you want the maintained version of this idea, the README points at the Templates directory for Next.js starters. The license is MIT.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. shadcn-ui/taxonomy on GitHub