Give us an api.json and we transform it into static API docs.
A pnpm monorepo (npm org @tsdoctor) of tools for generating API documentation from Microsoft API Extractor models. API Extractor distills a TypeScript package's public surface into a single .api.json file; tsdoctor turns that file into a static documentation site — one page per API item, syntax-highlighted signatures with Twoslash hover tooltips, type references that cross-link between pages, and per-package llms*.txt files so agents get the same documentation humans do. LLM-first output and crawlable SEO are core missions, not add-ons.
The core @tsdoctor/* libraries are framework-neutral. Framework adapters wire them into a specific static-site generator: RSPress today, VitePress planned. The repo was renamed from spencerbeggs/rspress-plugin-api-extractor (GitHub redirects the old URL), and the RSPress plugin keeps its original npm name.
| Package | npm | Description |
|---|---|---|
| rspress-plugin-api-extractor | published | The RSPress 2.0 adapter: reads .api.json models and generates an interactive documentation site with Twoslash tooltips, cross-linking, multi-package portals, multiVersion, i18n and LLMs integration |
A VitePress adapter is planned as platforms/vitepress; it gates the core packages' 1.0 release.
Framework-neutral @tsdoctor/* libraries under packages/, consumed by the adapters:
| Package | npm | Description |
|---|---|---|
| @tsdoctor/model | published | Pure api.json loading, TSDoc extraction, type-signature formatting, declaration reconstruction and per-item markdown rendering |
| @tsdoctor/registry | published | External package type loading: fetch, cache and resolve type definitions from npm into a virtual file system for Twoslash tooling |
| @tsdoctor/vfs | unreleased | The virtual TypeScript project: the Vfs type, declaration-backed virtual packages, @typescript/vfs environments and compiler-option resolution |
| @tsdoctor/bundle | unreleased | The tsdoctor bundle spec: layered bundle discovery, the versioned tsdoctor.json sidecar manifest, provenance-carrying resolution and canonical input hashing |
| @tsdoctor/snapshot | unreleased | Incremental-build snapshot tracking: a schema-versioned SQLite store of per-file content hashes and timestamps, built on @effected/store |
| @tsdoctor/seo | unreleased | Framework-neutral <head> metadata: canonical URLs, Open Graph and Twitter cards, package attribution and schema.org JSON-LD, behind one headTags seam |
The predecessors of the first two — type-registry-effect and api-extractor-llms — are deprecated on npm in favor of @tsdoctor/registry and @tsdoctor/model.
The remaining workspaces are private fixtures that exercise the plugin end-to-end:
| Workspace | Purpose |
|---|---|
| modules/ | TypeScript fixture libraries (kitchensink, effect-kit, versioned-v1/v2) that build the .api.json models the sites consume |
| sites/ | RSPress fixture sites, one per supported configuration: single API (basic), multiVersion (versioned), i18n, multi-API portal (multi) and Effect-TS patterns (effect) |
The repo also ships a companion Claude Code plugin, api-docs, under plugin/. It is not a pnpm workspace; load it locally with pnpm claude.
Install rspress-plugin-api-extractor in your own site and start with the guides in docs/:
- Getting started — Install the plugin, point it at one API Extractor model and run your first build.
- Configuration — Every option the plugin accepts, organized by where it lives.
- Config helpers — Discover model, package.json and tsconfig fields from a package folder instead of writing them out by hand.
- Single package — The single-package recipe documents one library.
- Multi-package — A multi-API portal documents several packages from one RSPress site.
- Versioned — Document each major version side by side with RSPress multiVersion.
- i18n — Document a package across locales with RSPress internationalization.
- Multi-entry points — Re-export deduplication, the "Available from" line and fail-fast route collisions.
- LLMs — Per-package llms*.txt files and in-page assistant actions.
- Runtime components — The importable runtime components and live with-api code blocks.
- Troubleshooting — The build problems you are most likely to hit, and what each one means.
pnpm install
pnpm run build # build the core libraries, the plugin and the fixture modules (not the sites)
pnpm dev # serve the basic fixture site with hot reloadEach fixture site has a matching pair of scripts — pnpm dev:<site> and pnpm preview:<site> for basic, versioned, i18n, multi and effect. Setup, the build pipeline, testing and the commit and pull-request flow live in CONTRIBUTING.md.
- Node.js >=24.11.0
- pnpm 11.x