shadcn-docs-nuxt: a docs template you copy and own, not a package you depend on

A template for the whole site, not a library of components

Most component libraries arrive as a dependency: you install a package, import a few names, and the library upgrades with a lockfile change. shadcn-docs-nuxt works the other way around. It is a complete Nuxt site, styled, wired to Nuxt Content, and designed to be copied into your own repository and edited until it no longer resembles the original. The npm package exists, but the README directs you to a starter repository rather than to the package for the first step.

That choice defines who the project is for. The audience is a team that has decided on Vue and Nuxt, has a product or a library to document, and wants a professional looking documentation site without hiring a designer or assembling a layout, sidebar, search and dark mode from parts. The credits section is explicit about the lineage: Nuxt Content for the content layer, shadcn-ui and its Vue port shadcn-vue for the component and design language, Docus for inspiration and some component source, and the Nuxt UI Pro Docs template for visual direction.

The site itself is published at shadcn-docs-nuxt.vercel.app as documentation and demo, so you can judge the result before touching a terminal. A Discord link is offered for questions, and the README lists the projects already using the template, which is more useful evidence of the audience than any feature list.

Two Nuxt apps in one repository, plus a published package

The repository layout does something that surprises people at first reading. The tree contains both an app/ directory and a www/ directory, and every command in package.json targets the www directory explicitly. The scripts are:

    "build": "nuxt prepare && nuxt build www",
    "dev": "nuxt prepare && nuxt dev www",
    "generate": "nuxt prepare && nuxt generate www",
    "preview": "nuxt prepare && nuxt preview www",

So the docs application lives in www/, and the build and preview commands are scoped to it. The presence of pnpm-workspace.yaml alongside pnpm-lock.yaml indicates a workspace setup, where more than one package shares a lockfile. The package.json declares [email protected] as its packageManager, and the README's contributing steps use pnpm commands, so pnpm is the intended tool even though the quick start uses npm.

The npm package is a curated slice of the repository. Its files array lists app, app.vue, assets, components, composables, i18n, layouts, lib, nuxt.config.ts, pages, plugins and types. Anything not on that list, such as the scripts and the workspace configuration, is not what you get from the package. That distinction matters if you plan to install rather than copy, and it is also where you should look first if you hit a missing file.

Getting a running site with nuxi init and a starter repository

The quick start is three steps, and the first one is the one that matters. Rather than cloning this repository, the README asks you to create a project from a separate starter template:

npx nuxi@latest init -t github:ZTL-UwU/shadcn-docs-nuxt-starter

That command asks the Nuxt CLI to scaffold a project from the starter repository on GitHub, so the result is a fresh directory with the template already in place. You then move into it and start the dev server:

cd [project-name]
npm run dev

The dev script runs nuxt prepare first, which regenerates the typed content and route artefacts Nuxt relies on, and then starts the development server against www. Because the script targets www, a dev server started from the repository root serves the docs application, not the other app in the tree.

For people working on the template itself rather than a site built from it, the README gives a different route: clone the repository, install dependencies with pnpm install, run pnpm run dev, and before committing run pnpm run lint:fix and pnpm run typecheck. Those two checks exist because the repository ships eslint.config.js and tsconfig.json, so a fork inherits the same linting and type checking rather than starting from scratch.

The dependency set tells you what the template actually does

The dependency list is the closest thing to a feature list, and it is worth reading as one. Nuxt Content is present as @ztl-uwu/nuxt-content, a scoped package rather than the plain upstream one, which is a fork published under the template author's own scope. The content layer is therefore pinned to a specific fork's release rather than tracking upstream automatically.

On the presentation side there is shadcn-nuxt, the Nuxt module for the shadcn-vue component set, plus reka-ui, class-variance-authority and clsx. components.json at the top of the repository is the shadcn configuration file, which is what lets you add components through the shadcn workflow rather than hand writing each one. The icon set is Iconify, with lucide and vscode-icons packages preinstalled for the icons a developer documentation site actually needs.

Around that sit the Nuxt modules a docs site needs quietly: @nuxt/fonts, @nuxt/image, @nuxt/icon, @nuxt/scripts, @nuxtjs/color-mode for light and dark switching, @nuxtjs/i18n for translations, and nuxt-og-image for Open Graph images. mermaid is included, so a diagram in Markdown has a renderer available. The result is a fairly heavy dependency set for a starter, and every one of those choices is a decision you inherit on day one and can remove later.

Internationalisation and i18n routing are already in place

The i18n/ directory at the top of the repository, together with the @nuxtjs/i18n dependency, means the template ships with locale handling configured rather than leaving you to add it after launch. For a documentation site this is often the difference between a one language setup and a rewrite, since routing, the language switcher and the translations all have to agree with each other.

The credit for the docs component source goes to Docus and to shadcn-vue, and that is worth understanding when you compare this project with other ways to publish Nuxt documentation. The difference in approach is ownership. You install a framework and it keeps evolving underneath you, with its own release cycle and its own conventions for where content and pages go. shadcn-docs-nuxt is an application. You own the whole thing, including the parts you will never touch, and you pick up template changes by merging from the template repository rather than by bumping a version number.

The cost of that ownership shows up over time rather than on day one. There is no automated way to pull upstream fixes into a fork that has been heavily edited, so the template effectively stops receiving updates once you diverge. The README's own copy and paste advice for contributors is manual, which is the same pattern your team will follow.

Where a copy-and-own template is the wrong choice

The most obvious limit is versioning. package.json pins a long list of exact-ish versions with carets, including shadcn-nuxt, @ztl-uwu/nuxt-content, @nuxtjs/i18n, nuxt-og-image and reka-ui, and a fork that changes its own files will not receive compatible updates for any of them automatically. A team that expects to run npm update or a dependency bot and have a working site is signing up for manual work here.

The second limit is the absence of a content authoring story for non-engineers. The content layer is Markdown under Nuxt Content, and the layout is Vue components in components/. That combination is comfortable for a developer and unpleasant for a documentation manager, and the README does not document a headless CMS route, a Git based editing workflow, or a preview branch setup for non-technical reviewers.

A third gap shows in the scripts. package.json defines build, dev, generate, preview, typecheck, lint and lint:fix, and the repository includes a taze.config.ts, but there is no test script in that list, so the taze configuration has no matching command in the scripts the README shows. Deployment is also not documented: the demo lives on Vercel, the package exposes a generate command that produces static output, and the README says nothing about how the site is deployed or how to configure a custom domain.

Release history, licence and the cost of keeping a fork current

The repository is not archived, and the last push was on 2026-09-12. Published releases are v1.2.0 on 2026-04-22, v1.2.1 on 2026-05-01 and v1.2.2 on 2026-05-17, and package.json carries version 1.2.2, so the npm artifact and the latest tag match. The template is distributed on npm under the name shadcn-docs-nuxt, and the README carries a pkg.pr.new badge pointing at a preview build of the package.

The licence is MIT, and the credits section names the upstream projects the template borrows components and design from, which is a courtesy request rather than a licence condition. MIT itself is permissive enough that a company can fork the template, drop the credits, and ship it without further obligations.

For a team already running Nuxt, the real upgrade cost is the one the licence does not mention: the pinned dependency set, the fork merge work, and the i18n/ and components/ conventions that your own developers have to learn. That cost is paid once at adoption and again every time the template ships a meaningful change, which is the trade the project is asking you to make.

Editorial conclusion

shadcn-docs-nuxt is a good fit for a Vue or Nuxt team that wants a branded documentation site this week rather than a documentation platform, and it is a poor fit for a team that wants components it can upgrade with a package manager, publish a docs site from a monorepo, or hand documentation over to editors who do not want to run Node. Before you commit, open the starter repository and check three things the README leaves open: whether the app/ and www/ split matches how you organise your own repository, whether the shadcn-nuxt and @ztl-uwu/nuxt-content versions pinned in package.json still install cleanly on your Node version, and whether the i18n/ directory is enough for the locales you plan to publish.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. ZTL-UwU/shadcn-docs-nuxt on GitHub