pdfcn: copy-paste PDF components for React, built on Takumi and Forme

What pdfcn actually ships: a registry, not a runtime package

The repository is a pnpm and Turborepo monorepo. The root package.json is private, declares workspaces for apps/* and packages/*, and its scripts delegate to Turbo with a filter on the web app: dev, build and start all run through turbo run with --filter=web, and there is a registry:build script that does the same. That layout tells you where the product lives. The thing you consume is a registry, built from the web app, and the components are copied into your project the way shadcn/ui components are. The README states the project uses "the same registry format and CLI workflow" as shadcn/ui, and that you "own the code." This is the central design decision. There is no pdfcn runtime dependency that receives upstream fixes. When a component changes upstream, your copy does not move until you re-run the add command and reconcile the diff. For teams that have been burned by a PDF library changing its layout engine between minor versions, that is the appeal. For teams that want a version number in a lockfile and a changelog, it is a cost.

Two rendering bases: Takumi and Forme

pdfcn does not implement PDF generation itself. The README lists "Two rendering bases" as the first feature: generate PDFs with Takumi or Forme. Takumi is linked at takumi.kane.tw/docs/pdf and Forme at docs.formepdf.com, and the repository topics include rust and wasm alongside react and typescript, which is consistent with rendering engines compiled to WebAssembly and driven from JavaScript. The practical consequence is that pdfcn is a component and document layer sitting on top of an engine you choose. Components and blocks (tables, forms, charts, invoices, reports, according to the README) are the part pdfcn contributes; pagination, font embedding and text layout are the engine's problem. That split is worth understanding before you adopt, because it means two support surfaces: the copied components in your repo, and whichever engine you picked. A layout bug that shows up in a generated invoice may be a pdfcn component issue or an engine issue, and the README does not describe how to tell them apart.

Installing pdfcn and rendering a first document

The README points to an installation page at pdfcn.vercel.app/docs/installation and describes setup as "Zero config, one command." The repository does not reproduce that command in the README text, so the exact invocation should be taken from the installation page rather than guessed. What the README does establish is the workflow: shadcn-compatible registry items added through the same CLI you already use for shadcn/ui. If you have a shadcn project, the shape of the command is the familiar add form, and the component source lands in your repository where you can edit it.

The monorepo's own toolchain is documented in the root package.json, and it is worth matching if you plan to run the docs app locally or contribute. Node 20.9.0 or newer and pnpm 10.0.0 or newer are required by the engines field.

pnpm install
pnpm dev

The dev script runs turbo run dev --filter=web, so you get the documentation app with its live previews rather than a library build. The README notes that every component and block is rendered directly in the documentation, which makes that local run the fastest way to see what a component produces before copying it into your own project.

For the registry itself, the root exposes a dedicated build step:

pnpm registry:build

That runs turbo run registry:build --filter=web. If you fork pdfcn to publish your own components, this is the command that regenerates the registry output. If you are only consuming components, you will not need it.

Where pdfcn is the wrong choice

The copy-paste model has a failure mode that is easy to underestimate. Every component you add becomes your code. If pdfcn fixes a pagination edge case in a table block three months from now, nothing in your project changes, because there is no dependency to update. You have to notice the upstream change, re-run the add command, and merge. On a project with a dozen registry items, that is a recurring chore, and the repository does not document a diff or upgrade workflow for it. The README's own framing, "Copy, paste, and ship," is honest about the trade: you get control, you take on maintenance.

The second boundary is the React requirement. pdfcn is a set of React components. If your PDF generation runs in a Go service, a Python worker, or a JVM batch job, the component layer is not usable there, and you would be looking at Takumi or Forme directly. The repository is TypeScript throughout and the root package.json declares "type": "module", so the whole toolchain assumes a modern ESM JavaScript environment.

The third is maturity signals. The project is not archived and the last push was on 2026-09-15, so it is current. But the repository lists no releases, which means there is no published version history to reason about. For a registry-style project that may be intentional, since the registry is the distribution channel, but it also means you cannot answer "what changed since I copied this" from a changelog.

pdfcn versus rendering React to PDF with a single library

The obvious alternative is a monolithic React-to-PDF renderer: one package that owns both the component primitives and the rendering engine, installed as a dependency and upgraded as a unit. The difference in approach is not cosmetic. With a single library, layout behaviour and component API are versioned together, so upgrading is one decision and one changelog. With pdfcn, the components are yours and the engine is a separate moving part, which means you can swap or upgrade the renderer without rewriting your document components, but you also own the glue between them.

A second comparison point is the engine choice itself. Because pdfcn supports both Takumi and Forme, the project is implicitly telling you that the component layer is not tightly coupled to either. That is a real architectural claim, and it is the main reason to prefer this over a single-engine component set: if one renderer stops working for your deployment target (a serverless runtime, a container without the right native dependencies), the components are not stranded. The README does not describe how much component code is engine-specific, so the portability is a claim to verify rather than assume.

Licence and the cost of owning copied components

pdfcn is MIT licensed, and the LICENSE file is at the repository root. MIT is permissive: you can use, modify and redistribute the components, including in commercial and closed-source products, provided the copyright notice and permission notice are retained. That matters more here than for a normal dependency, because you are copying source into your own repository rather than importing a package. The practical implication is that attribution travels with the copied files. This is not legal advice; if your organisation has strict rules about notice retention, check how your registry CLI writes the copied files before you add a dozen of them.

Upgrade cost is the other side of the licence. Because there is no versioned package, the upgrade path is re-running the add command and reviewing the diff against your edited copies. Teams that treat registry items as vendored code and keep their modifications minimal will find this manageable. Teams that heavily customise every component will find that each upstream change becomes a merge conflict. The repository's own tooling (lefthook for git hooks, oxlint and oxfmt for linting and formatting, ultracite as the check command) applies to contributing to pdfcn, not to your project, so do not expect it to help you maintain your copies.

Editorial conclusion

Adopt pdfcn if your team already writes React and wants invoice, report and table documents assembled from components you can edit, and if you accept that two rendering backends (Takumi and Forme) are the real dependency surface. Do not adopt it if you need a single stable package version to pin, or if your PDFs are generated in a language without a React toolchain. Before committing, read the installation page at pdfcn.vercel.app/docs/installation, confirm which of the two renderers your target environment supports, and check whether the registry items you need are listed under docs/components and docs/blocks.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. shadcn-labs/pdfcn on GitHub