MUI Docs Infra

Warning

This is an internal project, and is not intended for public use. No support or stability guarantees are provided.

Load Server Types Text

A function for parsing types.md files back into structured type metadata. This is the reverse operation of syncTypes - it reads markdown and reconstructs the TypesMeta[] array.

Overview

loadServerTypesText parses a types.md file that was previously generated by syncTypes. It reconstructs:

  • Component, hook, function, and raw type metadata
  • Props, parameters, data attributes, and CSS variables tables
  • External types section
  • Variant metadata (embedded as comments)

This is useful for:

  • Reading pre-generated documentation without re-running TypeScript analysis
  • Testing and debugging the type generation pipeline
  • Building tools that consume type documentation

Usage

Basic Usage

import { loadServerTypesText } from '@mui/internal-docs-infra/pipeline/loadServerTypesText';

// Load types from a file URL
const result = await loadServerTypesText('file:///absolute/path/to/types.md');

// Access the parsed types
console.log(result.allTypes); // TypesMeta[]
console.log(result.variantData); // Record<string, VariantData>
console.log(result.externalTypes); // Record<string, string>

Parsing Markdown Directly

import { parseTypesMarkdown } from '@mui/internal-docs-infra/pipeline/loadServerTypesText';

const markdown = `# Button API

## API Reference

### Button

A clickable button component

**Button Props:**

| Prop | Type | Default | Description |
| --- | --- | --- | --- |
| disabled | \`boolean\` | \`false\` | Whether the button is disabled |
| onClick* | \`() => void\` | - | Click handler |
`;

const result = parseTypesMarkdown(markdown);
console.log(result.allTypes[0]); // { type: 'component', name: 'Button', data: {...} }

Functions

loadServerTypesText

Loads and parses a types.md file from a file URL.

async function loadServerTypesText(fileUrl: string): Promise<LoadServerTypesTextResult>;

Parameters:

ParameterTypeDescription
fileUrlstringA file:// URL to the types.md file

parseTypesMarkdown

Parses markdown content directly into type metadata. Exported for testing.

function parseTypesMarkdown(content: string): LoadServerTypesTextResult;

Parameters:

ParameterTypeDescription
contentstringThe raw markdown content to parse

Markdown Format

The parser expects markdown in the format generated by syncTypes:

Type Sections

Each type is defined by an H3 heading (###) followed by optional description and tables:

### ComponentName

Optional description paragraph.

**ComponentName Props:**

| Prop       | Type      | Default     | Description                    |
| ---------- | --------- | ----------- | ------------------------------ |
| propName   | `string`  | `"default"` | Prop description               |
| required\* | `boolean` | -           | Required prop (marked with \*) |

Type Detection

The parser determines type kind based on content:

  • Hook: Name starts with use
  • Component: Has props, data attributes, or CSS variables
  • Function: Has parameters or return value
  • Raw: Has a code block definition

Tables

The parser recognizes these table formats:

  • Props: | Prop | Type | Default | Description |
  • Parameters: | Parameter | Type | Default | Description |
  • Data Attributes: | Attribute | Type | Description |
  • CSS Variables: | Variable | Type | Description |
  • Return Value: | Property | Type | Description |

External Types

External types are parsed from the "External Types" H2 section:

## External Types

### TypeName

\`\`\`typescript
type TypeName = string | number;
\`\`\`

Embedded Metadata

Variant and type name mappings are embedded as HTML comments at the end of the file:

[//]: # 'variantTypes: {"Default":["Button","ButtonProps"]}'
[//]: # 'typeNameMap: {"ButtonProps":"Button.Props"}'

Types

loadServerTypesText

loadServerTypesText

Load and parse a types.md file into TypesMeta[].

ParameterTypeDescription
fileUrlstring

file:// URL to the types.md file

Return Type

Parsed types and external types

organizeTypesByExport

organizeTypesByExport

Organizes types data by export name and computes slugs.

The logic categorizes types as follows:

  • Component/hook/function types become the main type in their export
  • Types ending in .Props, .State, .DataAttributes, etc. become additionalTypes for their export
  • Non-namespaced types (no dot in the name) go to top-level additionalTypes

Each type is also assigned a slug for anchor linking (e.g., “trigger” or “trigger.props”).

ParameterTypeDescription
variantDataRecord<string, { types: BaseTypeMeta[]; typeNameMap?: Record<string, string> }>

The variant data containing types per variant

typeNameMapRecord<string, string> | undefined

Optional map from flat names to dotted names

Return Type
KeyTypeDescription
exportsRecord<string, { type: BaseTypeMeta; additionalTypes: BaseTypeMeta[] }>

Export data where each export has a main type and related additional types

additionalTypesBaseTypeMeta[]

Top-level non-namespaced types like InputType

variantTypeNamesRecord<string, string[]>

Maps variant names to the type names that originated from that variant. Used for namespace imports (e.g., * as Types) to filter additionalTypes to only show types from that specific module.

variantTypeNameMapsRecord<string, Record<string, string>>

Maps variant names to their per-variant typeNameMaps. Used for Canonical Types annotations showing which variants contain each type.

Additional Types

BaseTypeMeta

Base type metadata interface used for organizing exports. This is a minimal interface that works with both TypesMeta and EnhancedTypesMeta.

type BaseTypeMeta = {
  name: string;
  type: 'component' | 'hook' | 'function' | 'class' | 'raw';
  slug?: string;
  data: unknown;
};
componentExports

Defines the order in which exports should be sorted in generated documentation.

Top-level order:

  • Components are listed in the order they appear in Base UI documentation
  • Namespace member suffixes (Props, State, etc.) are listed in their conventional order
  • EVERYTHING_ELSE captures any remaining types

Component namespace members are automatically grouped with their parent component. For example, “Accordion” will be followed by “Accordion.Root”, “Accordion.Item”, etc. The namespace members themselves are sorted by the suffix order defined below.

type componentExports = string[];
cssVariables
type cssVariables = any[];
dataAttributes
type dataAttributes = string[];
namespaceParts
type namespaceParts = string[];
OrganizeTypesResult

Result of organizing types by export.

type OrganizeTypesResult = {
  exports: Record<string, { type: BaseTypeMeta; additionalTypes: BaseTypeMeta[] }>;
  additionalTypes: BaseTypeMeta[];
  variantTypeNames: Record<string, string[]>;
  variantTypeNameMaps: Record<string, Record<string, string>>;
};
props
type props = string[];
TypesSourceData

Common data returned by both syncTypes and loadServerTypesText. This is the shared contract consumed by loadServerTypes.

type TypesSourceData = {
  externalTypes: Record<string, string>;
  typeNameMap: Record<string, string>;
  allDependencies: string[];
  updated: boolean;
  exports: Record<string, { type: TypesMeta; additionalTypes: TypesMeta[] }>;
  additionalTypes: TypesMeta[];
  variantTypeNames: Record<string, string[]>;
  variantTypeNameMaps: Record<string, Record<string, string>>;
};
typeSuffixes
type typeSuffixes = string[];
VariantData

Variant data structure for a single variant. Contains the types and optional typeNameMap specific to that variant.

type VariantData = { types: TypesMeta[]; typeNameMap?: Record<string, string> };

Related

  • syncTypes - Generates the types.md files that this function parses
  • loadServerTypes - Full pipeline that calls syncTypes and applies highlighting