Orientation
Content Processing
Search Infrastructure
Rendering and UI
Developer Tooling
How It Works
The following files were used as context for generating this wiki page:
Fumadocs utilizes a monorepo architecture managed via pnpm workspaces, designed to decouple documentation core logic, UI implementations, and ecosystem integrations. This structure solves the complexity of managing shared documentation primitives (like page trees, search indexing, and MDX processing) alongside multiple frontend UI libraries and build-tool plugins.
The project is segmented into distinct packages under the packages/ directory. Each package serves a single responsibility: fumadocs-core provides the foundation, while specialized packages like fumadocs-ui (Radix UI based) or base-ui (Base UI based) offer alternative implementations of visual components. Integrations for specific ecosystems—such as MDX, TypeScript documentation, AsyncAPI, and Python source generation—are likewise separated, ensuring that a consumer only installs the dependencies required for their specific use case.
This modularity is enforced through a strict tsdown configuration and explicit exports definitions in each package.json. By isolating cross-cutting concerns like search, navigation, and i18n into their own sub-paths, the project minimizes bundle size for end users and allows for independent versioning and testing of components, providing a robust surface area for extensibility and integration.
The workspace is managed by pnpm-workspace.yaml, which defines the scope of packages available for development. The root package.json coordinates cross-package tasks using turbo, facilitating global build, lint, and test cycles.
Sources: pnpm-workspace.yaml:1-4, package.json:5-17
fumadocs-core acts as the engine, housing fundamental documentation structures. It is built using tsdown, which generates ESM output. The core package structure emphasizes functional composition, with modules like page-tree, search, and mdx-plugins providing the logic for transforming source content into renderable documentation structures.
Fumadocs utilizes a registry-based approach for UI components, similar to CLI-driven distribution patterns. The packages/base-ui and packages/radix-ui registries define how components are structured, listed, and written to user codebases.
The registry logic uses a findSlotComponents function imported from the shared module to dynamically discover and register UI components. This allows the CLI to manage component installation without manual registration of every file.
Specialized packages handle non-React content sources. For instance, the packages/python package provides a robust interface for generating documentation from Python source code, utilizing a ModuleInterface that defines how docstrings and metadata are structured.
Note
The DocstringSection type in packages/python/src/generated.ts uses a tagged union pattern (kind) to differentiate between text blocks, code examples, and admonitions, allowing the rendering engine to correctly map complex docstrings to React components.
The system handles environment-specific requirements through internal peerDependenciesMeta and inlinedDependencies fields. This ensures that packages can rely on necessary runtime dependencies (like react or next) while marking them as optional for consumers who might use alternative configurations.
The CLI tooling acts as the glue for the registry system, using packages/cli/src/commands/shared.ts to map internal UI names to registry keys. This allows the create-app package to standardize initialization across different template types (e.g., Next.js, Waku, TanStack Start).
+next+fuma-docs-mdx).create-app/src/constants.ts resolves the workspace versions for the selected template.rootProviderPath (e.g., app/layout.tsx).base-ui or radix-ui) is copied into the consumer directory according to the target path definition in the registry.