Development

Project structureCopy Anchor Link

The docs site lives in the same monorepo as the packages:

tablecn/
├── apps/web/                      # this site (Next.js + Fumadocs)
│   ├── content/docs/              # MDX docs pages
│   ├── registry/{radix,base,aria} # table and filter UI, one folder per primitive library
│   ├── registry.json              # shadcn registry definition
│   └── public/r/                  # built registry
└── packages/
    ├── filter-core/               # @querycn/filter-core
    ├── filter-react/              # @querycn/filter-react
    ├── filter-next/               # @querycn/filter-next
    ├── table-react/               # @querycn/table-react
    └── ui/                        # shared shadcn/ui components for this site

RequirementsCopy Anchor Link

• Node.js 20.6 or later
• pnpm 10 (the repo pins it in packageManager)

Install dependenciesCopy Anchor Link

pnpm install

Start the dev serverCopy Anchor Link

pnpm dev

Open http://localhost:3000 for the app and /docs for the documentation. pnpm dev builds the shadcn registry into apps/web/public/r first.

ChecksCopy Anchor Link

Run these from the repository root:

pnpm typecheck
pnpm lint
pnpm test

RegistryCopy Anchor Link

The table and filter UI live in apps/web/registry/{radix,base,aria}/{table,filter}, described once in apps/web/registry.json. Rebuild the registry after changing either:

pnpm registry:build

This writes apps/web/public/r/{radix,base,aria}/*.json: one JSON file per block and primitive library, each holding the component sources and their dependencies. Next.js serves them at /r/<base>/<name>.json, and at /r/{style}/<name>.json for the @tablecn namespace, which is what npx shadcn add downloads.

The folder is committed, so the registry can also be read straight from GitHub. After changing a registry component, run pnpm --filter web registry:build and commit public/r with it; CI fails when it's out of date. pnpm dev and pnpm build rebuild it too.

ReleasesCopy Anchor Link

1. For a change to a package, add a changeset: pnpm changeset. The Release workflow keeps a Version Packages pull request open; merging it publishes to npm.
2. When a block starts using a new package version, raise that package's range in apps/web/registry.json (on 0.x, ^0.3.0 doesn't accept 0.4.0), and rebuild the registry.
3. Add what users will notice to the Changelog: what's new, changed or fixed, and what to do when updating. Changes to the blocks belong there too, even without a package release.
4. pnpm installs a version only a day after it's published. When a block needs a new package version, publish the packages first and push the block changes a day later, or pnpm users can't add the block until then.

Build for productionCopy Anchor Link

pnpm build