Compare documentation tools

Two choices shape a documentation site: how closely it should follow your product’s design system and where its content comes from. Cookbook was built for both. Its theme is configurable down to named component parts, and its content can come from existing repository files or a published npm package. Turning Markdown into pages is only one part of that workflow.

The comparisons below describe each tool’s documented starting workflow, not every integration its users could build. They are a selection of established options, not a popularity ranking or an exhaustive list.

Cookbook treats appearance as a supported configuration surface rather than a set of selectors to override after rendering:

• Set one theme.brand color or define semantic theme.palette roles. Glaze resolves them for light, dark, normal, and high-contrast modes, with contrast targets and diagnostics.
• Configure shared theme.tokens, font roles, typography theme.presets, and responsive theme.states once. Components consume those roles consistently.
• Change a built-in component through a partial theme.styles.<ComponentName> Tasty object. Cookbook merges it into the full base style before extracting CSS. Its named component parts are published so a header title, search field, or sidebar item can be changed without copying an entire component.
• Add a styled component with defineComponent() or replace markup and behavior through an Astro component override when the supported anatomy is not enough. Tasty and Glaze run during the build; the browser receives static CSS, not their styling runtimes.

For example, this changes the brand, a shared radius, heading typography, and one part of the header while keeping the other default component styles:

import { defineDocsConfig } from "@tenphi/cookbook/config";

export default defineDocsConfig({
  theme: {
    brand: { from: "#315efb" },
    tokens: { $radius: "10px" },
    presets: { heading: { fontWeight: 650 } },
    styles: { Header: { SiteTitle: { preset: "h4 / strong" } } },
  },
});

This style contract is specific to Cookbook’s Tasty and Glaze system. Structural changes still require an Astro override. Read the customization rules, theme guide, and component styles reference for the supported configuration and names.

• A repository README.md and docs/ tree: Start with Cookbook, Starlight, VitePress, or another site builder. Choose the framework and editing workflow you prefer; Cookbook can read the existing files in place.
• Markdown inside a published npm package: Cookbook’s package source reads the published artifact, pins its version and integrity, and builds without installing that package.
• TypeScript exports and code comments: TypeDoc generates reference pages from the code model and can use package entry points.
• UI components and their stories: Storybook Autodocs documents components alongside rendered stories.
• An OpenAPI specification: Choose Cookbook’s static reference or a tool with an interactive API playground if readers need to make requests from the docs.

All of these tools support visual customization. Their default content and styling contracts differ:

The table compares documented approaches, not a ceiling on what each tool can do. Choose the styling model you want to maintain. Cookbook’s model is useful when brand, typography, semantic colors, and component anatomy must move together across the whole site. Starlight, Docusaurus, VitePress, Nextra, and Material for MkDocs provide their own routes to theme or component changes; Mintlify provides a managed editing and hosting workflow. Cookbook requires an Astro build and a host for its static output. Starlight plugins target its own APIs and do not run in Cookbook; see Cookbook extensions.

“Package to website” can mean two different jobs:

1. Publish the prose included in an npm release. Cookbook reads the actual tarball’s selected README.md and Markdown files. Package MDX requires an explicit trust opt-in before its code can run. cookbook update records the requested specifier, resolved version, and integrity in cookbook.lock.json; a production build uses that lock. This is useful when the docs site should describe exactly what package consumers received. See package sources and the package quick start.
2. Generate reference pages from source code. TypeDoc reads TypeScript exports and comments, including entry points discovered from package.json, and emits an HTML or JSON reference. It is the direct choice when exported types and signatures are the documentation.

For a component library, Storybook is a separate option when the main experience should be runnable component examples. TypeDoc or Storybook can complement a guide site; link to their output from Cookbook navigation when each serves a different reader need.

Cookbook does not extract API signatures from TypeScript or provide an interactive OpenAPI client. Its strengths are design system customization, source-aware prose, validated links and assets, and a reproducible npm artifact input. See content sources and theme and components for the supported scope.