@fusion.dev/helix-docs 0.0.0-dev

package/dist/pages.generated.js

@@ -0,0 +1,284 @@
+export const docPages = [
+    {
+        description: 'What the library guarantees, what it cannot, and where the line is.',
+        section: 'Foundations',
+        slug: 'accessibility',
+        title: 'Accessibility',
+    },
+    {
+        description: 'The schema Angular needs before it will compile an unknown tag.',
+        parent: 'installation',
+        section: 'Getting started',
+        slug: 'angular',
+        title: 'Angular',
+    },
+    {
+        description: 'The platform features this is built on, and what is actually tested.',
+        order: 5,
+        section: 'Getting started',
+        slug: 'browser-support',
+        title: 'Browser support',
+    },
+    {
+        description: 'Using the headless tier as the foundation for a design system of your own.',
+        section: 'Essentials',
+        slug: 'building-on-the-headless-tier',
+        title: 'Building on the headless tier',
+    },
+    {
+        description: 'The data channel nobody expects, and why it is a real table.',
+        section: 'Essentials',
+        slug: 'charting',
+        title: 'Charting',
+    },
+    {
+        description: 'Every surface here is readable by a machine, and where each one is.',
+        order: 4,
+        section: 'Getting started',
+        slug: 'coding-agents',
+        title: 'Coding agents',
+    },
+    {
+        description: 'The roles, the ramps, and why the palette is solved rather than picked.',
+        section: 'Foundations',
+        slug: 'color',
+        title: 'Color',
+    },
+    {
+        description: 'One attribute, two modes, and no token restated to honor it.',
+        section: 'Foundations',
+        slug: 'color-modes',
+        title: 'Color modes',
+    },
+    {
+        description: 'Families, parts and groups, and which to reach for.',
+        section: 'Essentials',
+        slug: 'composition',
+        title: 'Composition',
+    },
+    {
+        description: 'Five layers, four shadows, and the glass the material tokens make possible.',
+        section: 'Foundations',
+        slug: 'elevation-and-material',
+        title: 'Elevation and material',
+    },
+    {
+        description: 'The request and the notification, why one name is prefixed and the other is not.',
+        section: 'Essentials',
+        slug: 'events',
+        title: 'Events',
+    },
+    {
+        description: 'Real form participation, labels that resolve across a shadow root, and the disabled trap.',
+        section: 'Essentials',
+        slug: 'forms',
+        title: 'Forms and validation',
+    },
+    {
+        description: '103 glyphs, one geometry, and how to draw one that is not in the set.',
+        section: 'Foundations',
+        slug: 'iconography',
+        title: 'Iconography',
+    },
+    {
+        description: 'What to install, the order the stylesheets go in, and how to check it worked.',
+        order: 3,
+        section: 'Getting started',
+        slug: 'installation',
+        title: 'Installation',
+    },
+    {
+        description: 'Every input the theme engine takes, and what each one decides.',
+        section: 'Theming',
+        slug: 'intent-reference',
+        title: 'Intent reference',
+    },
+    {
+        description: 'What Helix is, and the four packages it stacks into.',
+        order: 1,
+        section: 'Getting started',
+        slug: 'introduction',
+        title: 'Introduction',
+    },
+    {
+        description: 'Locale-aware controls, translatable strings, and a layout that already flips.',
+        section: 'Essentials',
+        slug: 'localization',
+        title: 'Localization and RTL',
+    },
+    {
+        description: 'What Helix costs a page, measured rather than claimed.',
+        order: 7,
+        section: 'Getting started',
+        slug: 'metrics',
+        title: 'Metrics',
+    },
+    {
+        description: 'Four durations, five curves, and the rule every animating component has to answer.',
+        section: 'Foundations',
+        slug: 'motion',
+        title: 'Motion',
+    },
+    {
+        description: 'The three rules every framework reduces to, and what they look like in each.',
+        parent: 'installation',
+        section: 'Getting started',
+        slug: 'other-frameworks',
+        title: 'Other frameworks',
+        trailing: true,
+    },
+    {
+        description: 'The top layer, what dismisses what, and where focus goes.',
+        section: 'Essentials',
+        slug: 'overlays',
+        title: 'Overlays and layering',
+    },
+    {
+        description: 'The three ways in past a shadow root, and which one to reach for.',
+        section: 'Theming',
+        slug: 'overriding-a-component',
+        title: 'Overriding a component',
+    },
+    {
+        description: 'The typings, the hydration bridge, and how state moves.',
+        parent: 'installation',
+        section: 'Getting started',
+        slug: 'react',
+        title: 'React',
+    },
+    {
+        description: 'Helix styling for markup this library does not render, with no JavaScript.',
+        section: 'Foundations',
+        slug: 'recipes',
+        title: 'Recipes',
+    },
+    {
+        description: 'Why a component renders its own anchor, and how to keep a router.',
+        section: 'Essentials',
+        slug: 'routing',
+        title: 'Routing and navigation',
+    },
+    {
+        description: 'The editor beside the preview, and how to build one of your own.',
+        section: 'Tooling',
+        slug: 'sandbox',
+        title: 'Sandbox',
+    },
+    {
+        description: 'What renders without a DOM, and what has to wait for one.',
+        section: 'Essentials',
+        slug: 'server-rendering',
+        title: 'Server rendering',
+    },
+    {
+        description: 'Five radii, two widths, and the two tokens that are a policy rather than a value.',
+        section: 'Foundations',
+        slug: 'shape-and-borders',
+        title: 'Shape and borders',
+    },
+    {
+        description: 'Why no control has a size, and what to write instead.',
+        section: 'Theming',
+        slug: 'size-and-density',
+        title: 'Size and density',
+    },
+    {
+        description: "One spacing scale, and why a control's height is not on it.",
+        section: 'Foundations',
+        slug: 'space-and-size',
+        title: 'Space and size',
+    },
+    {
+        description: 'Why a declared property is a seed, and how to take a decision when you want it.',
+        section: 'Essentials',
+        slug: 'state-and-control',
+        title: 'State and control',
+    },
+    {
+        description: 'The four ways a surface is told apart, and the ground a component is not.',
+        section: 'Foundations',
+        slug: 'surfaces-and-separation',
+        title: 'Surfaces and separation',
+    },
+    {
+        description: 'Typed tags, and the framework that needs the least said about it.',
+        parent: 'installation',
+        section: 'Getting started',
+        slug: 'svelte',
+        title: 'Svelte',
+    },
+    {
+        description: 'The tool that turns intent inputs into a token set you can see.',
+        section: 'Tooling',
+        slug: 'theme-builder',
+        title: 'Theme builder',
+    },
+    {
+        description: 'Deriving an accessible token set from intent inputs.',
+        section: 'Theming',
+        slug: 'theming',
+        title: 'Deriving a theme',
+    },
+    {
+        description: 'Why the headless and styled tiers are separate packages.',
+        order: 2,
+        section: 'Getting started',
+        slug: 'tiers',
+        title: 'Tiers',
+    },
+    {
+        description: 'The two layers, the surface ladder, and what is enforced.',
+        pinned: true,
+        section: 'Theming',
+        slug: 'tokens',
+        title: 'Tokens',
+    },
+    {
+        description: 'Three families, one scale, and a heading that is a real heading.',
+        section: 'Foundations',
+        slug: 'typography',
+        title: 'Typography',
+    },
+    {
+        description: 'The four things that look like a library bug and are not, and where an agent should read from.',
+        parent: 'coding-agents',
+        section: 'Getting started',
+        slug: 'using-helix-with-an-agent',
+        title: 'Using Helix with an agent',
+    },
+    {
+        description: 'Binding events, registering elements, and the traps in both.',
+        pinned: true,
+        section: 'Essentials',
+        slug: 'using-the-elements',
+        title: 'Using the elements',
+    },
+    {
+        description: 'What a version number means here, and which packages move together.',
+        order: 6,
+        section: 'Getting started',
+        slug: 'versioning',
+        title: 'Versioning',
+    },
+    {
+        description: 'Four words with fixed vocabularies, one escape hatch, and the word that is refused.',
+        section: 'Theming',
+        slug: 'visual-axes',
+        title: 'Visual axes',
+    },
+    {
+        description: 'The one compiler setting Vue needs, and why props and events already work.',
+        parent: 'installation',
+        section: 'Getting started',
+        slug: 'vue',
+        title: 'Vue',
+    },
+    {
+        description: 'A page that uses Helix with no build step, and what that costs.',
+        parent: 'installation',
+        section: 'Getting started',
+        slug: 'without-a-bundler',
+        title: 'Without a bundler',
+        trailing: true,
+    },
+];

package/dist/reference.d.ts

@@ -0,0 +1,105 @@
+/**
+ * The component reference, rendered from a manifest to markdown.
+ *
+ * **Pure, and it lives here rather than in a site.** A manifest-to-markdown
+ * renderer is documentation for Helix: a consumer installing `@fusion.dev/helix-docs`
+ * should get the component reference along with the prose, and a site should be
+ * one of its readers rather than its owner. It also has to be pure, because a
+ * content package that touched the filesystem would trace itself into every
+ * consumer's server bundle. Reading the manifest is the caller's job.
+ *
+ * **The styled tier only, which is not a shortcut.** A styled component extends
+ * its headless base, and the analyzer resolves inheritance across packages, so
+ * the styled entry already carries every inherited member with the base it came
+ * from named against it. Documenting both tiers would print most of the library
+ * twice to say the same thing.
+ *
+ * **First paragraph in a table cell, and the whole thing everywhere else.** A
+ * cell holding four paragraphs is a table nobody reads, so a property's own
+ * reasoning stays on the component and on `/components/<family>`, which renders
+ * the manifest in a browser. A component's description is not in a cell: it is
+ * prose under a heading, and truncating that threw away everything `Date
+ * Picker` says about its three modes.
+ */
+import type { HelixDeclaration, HelixManifest } from '@fusion.dev/helix-cem';
+/**
+ * An example, as much of one as a markdown reference prints.
+ *
+ * Structural rather than the catalog's `Example`, so this module does not
+ * import from one that imports it. Anything the catalog returns satisfies it.
+ */
+export interface ReferenceExample {
+    css: string;
+    description: string;
+    html: string;
+    label: string;
+}
+/** What to put above the reference, for a caller that generates a file. */
+export interface ReferenceOptions {
+    /**
+     * Examples to print under each family, keyed by family slug.
+     *
+     * **The reference `.md` carries the examples and the HTML page does not**,
+     * and the difference is deliberate rather than an omission on one side. That
+     * page answers what a component can do, and the sandbox beside it answers
+     * what the component looks like; a reference that started collecting pictures
+     * would stop being the one place you can trust to be complete. An agent has
+     * no sandbox to be sent to, and to it an example is text rather than a
+     * picture, so the `.md` is the only surface that has to answer both.
+     */
+    examples?: Record<string, ReferenceExample[]>;
+    /** Only these families. Omitted renders everything in the manifest. */
+    families?: string[];
+    /**
+     * Frontmatter, emitted above the heading.
+     *
+     * Provenance rather than decoration: a generated document should say what it
+     * was generated from, so a reader who finds one detached from this repository
+     * can still tell where to look. Keys are written in the order given, because
+     * a reader scans the first line and `title` is what they want there.
+     */
+    frontmatter?: Array<[string, string]>;
+    /** Prose under the heading, already wrapped. Omitted where absent. */
+    lede?: string[];
+    /** Top-level heading. */
+    title?: string;
+}
+/**
+ * The family and part a declaration belongs to, from where its file is.
+ *
+ * Not from the tag name. A tag is a string the family prefix can only be
+ * guessed out of: `helix-button-group` is one family and `helix-tab` is a
+ * part of another, and nothing in the name says which. The path says both.
+ */
+export declare const place: (path: string | undefined) => {
+    family: string;
+    part: string;
+};
+/** One family's declarations, in the order a reference prints them. */
+export interface ReferenceFamily {
+    family: string;
+    parts: Array<{
+        declaration: HelixDeclaration;
+        part: string;
+    }>;
+}
+/**
+ * Every family in a manifest, alphabetical, each with its parts.
+ *
+ * Root first inside a family, then the rest alphabetically. A family reads from
+ * the thing that holds the others, and `item` before `root` is alphabetical
+ * order telling you about the alphabet rather than about the component.
+ */
+export declare const referenceFamilies: (manifest: HelixManifest) => ReferenceFamily[];
+/**
+ * A manifest, as the markdown reference for everything in it.
+ *
+ * The caller supplies the manifest and whatever preamble belongs above it, so
+ * the same renderer serves the whole-library document in `docs/` and a
+ * per-family page without either one knowing about the other.
+ *
+ * **A single family gets no heading naming it**, because the title already
+ * does: a document about the accordion should not say Accordion twice before
+ * its first sentence. More than one and the headings are what separate them.
+ */
+export declare const reference: (manifest: HelixManifest, options?: ReferenceOptions) => string;

package/dist/reference.js

@@ -0,0 +1,181 @@
+import { startCase } from './naming.js';
+/**
+ * Whether a member belongs in a reference at all.
+ *
+ * Public only, and nothing inherited from `HelixElement`. Every component in
+ * the library extends it, so its members would appear on all of them: an
+ * `internals` field and two lifecycle methods that exist so components do not
+ * have to think about the shadow root. Printing them everywhere says the same
+ * infrastructural thing once per component and buries the four properties a
+ * consumer came to read.
+ *
+ * `HelixFormElement` is deliberately not on that list. What it contributes is
+ * form participation, which is the API of a form control.
+ */
+const INFRASTRUCTURE = new Set(['HelixElement']);
+const isPublic = (member) => member.privacy !== 'private' &&
+    member.privacy !== 'protected' &&
+    !INFRASTRUCTURE.has(member.inheritedFrom?.name ?? '');
+/** A cell's worth of a description: the first paragraph, on one line. */
+const cell = (text) => (text ?? '').split('\n\n')[0]?.replace(/\s+/g, ' ').replace(/\|/g, '\\|').trim() ?? '';
+/** A type, escaped so its unions do not end the column they are in. */
+const code = (text) => text ? `\`${text.replace(/\|/g, '\\|')}\`` : '-';
+/** A markdown table, or nothing at all where there are no rows to put in one. */
+const table = (depth, heading, columns, rows) => {
+    if (rows.length === 0) {
+        return '';
+    }
+    const head = `| ${columns.join(' | ')} |`;
+    const rule = `| ${columns.map(() => '---').join(' | ')} |`;
+    const body = rows.map((row) => `| ${row.join(' | ')} |`).join('\n');
+    return `\n${'#'.repeat(depth)} ${heading}\n\n${head}\n${rule}\n${body}\n`;
+};
+/**
+ * The family and part a declaration belongs to, from where its file is.
+ *
+ * Not from the tag name. A tag is a string the family prefix can only be
+ * guessed out of: `helix-button-group` is one family and `helix-tab` is a
+ * part of another, and nothing in the name says which. The path says both.
+ */
+export const place = (path) => {
+    const [, family = '', part = ''] = /^src\/([^/]+)\/([^/]+)\//.exec(path ?? '') ?? [];
+    return { family, part };
+};
+/**
+ * Every family in a manifest, alphabetical, each with its parts.
+ *
+ * Root first inside a family, then the rest alphabetically. A family reads from
+ * the thing that holds the others, and `item` before `root` is alphabetical
+ * order telling you about the alphabet rather than about the component.
+ */
+export const referenceFamilies = (manifest) => {
+    const families = new Map();
+    for (const module of manifest.modules ?? []) {
+        for (const declaration of module.declarations ?? []) {
+            if (!declaration.tagName) {
+                continue;
+            }
+            const { family, part } = place(module.path);
+            if (!family) {
+                continue;
+            }
+            families.set(family, [...(families.get(family) ?? []), { declaration, part }]);
+        }
+    }
+    return [...families]
+        .sort(([a], [b]) => a.localeCompare(b))
+        .map(([family, parts]) => ({
+        family,
+        parts: [...parts].sort((a, b) => a.part === 'root' ? -1 : b.part === 'root' ? 1 : a.part.localeCompare(b.part)),
+    }));
+};
+/** The tables for one element, in the order they are printed. */
+const element = (depth, declaration, part) => {
+    const { attributes = [], cssParts = [], cssProperties = [], description, events = [], members = [], slots = [], summary, superclass, tagName, } = declaration;
+    const lines = [`${'#'.repeat(depth)} ${startCase(part)} (\`${tagName}\`)`, ''];
+    if (summary) {
+        lines.push(summary, '');
+    }
+    if (superclass?.name) {
+        lines.push(`Extends \`${superclass.name}\`.`, '');
+    }
+    if (description) {
+        lines.push(description.trim(), '');
+    }
+    const attributeOf = new Map(attributes.map((one) => [one.fieldName ?? one.name, one.name]));
+    const named = (rows, kind) => rows
+        .filter((row) => row.kind === kind && isPublic(row))
+        .sort((a, b) => a.name.localeCompare(b.name));
+    lines.push(table(depth + 1, 'Properties', ['Property', 'Attribute', 'Type', 'Default', 'From', 'Description'], named(members, 'field').map((field) => [
+        `\`${field.name}\``,
+        attributeOf.has(field.name) ? `\`${attributeOf.get(field.name)}\`` : '-',
+        code(field.type?.text),
+        field.default ? `\`${field.default}\`` : '-',
+        field.inheritedFrom?.name ? `\`${field.inheritedFrom.name}\`` : '-',
+        cell(field.description),
+    ])).trimEnd(), table(depth + 1, 'Methods', ['Method', 'From', 'Description'], named(members, 'method').map((method) => [
+        `\`${method.name}()\``,
+        method.inheritedFrom?.name ? `\`${method.inheritedFrom.name}\`` : '-',
+        cell(method.description),
+    ])).trimEnd(), table(depth + 1, 'Events', ['Event', 'Type', 'Description'], events.map((event) => [`\`${event.name}\``, code(event.type?.text), cell(event.description)])).trimEnd(), table(depth + 1, 'Slots', ['Slot', 'Description'], slots.map((slot) => [
+        slot.name ? `\`${slot.name}\`` : '*(default)*',
+        cell(slot.description),
+    ])).trimEnd(), table(depth + 1, 'Parts', ['Part', 'Description'], cssParts.map((one) => [`\`${one.name}\``, cell(one.description)])).trimEnd(), 
+    /* A "From" column, because a hook can now arrive from a component this one
+       borrowed a stylesheet from rather than be its own. Without it a borrowed
+       `--icon-button-radii` reads on the Copy Button page as a hook Copy Button
+       named, and a consumer who guesses `--copy-button-radii` from that gets
+       nothing. See 290. */
+    table(depth + 1, 'Custom properties', ['Property', 'From', 'Description'], cssProperties.map((one) => [
+        `\`${one.name}\``,
+        one.inheritedFrom?.name ? `\`${one.inheritedFrom.name}\`` : '-',
+        cell(one.description),
+    ])).trimEnd(), '');
+    return lines;
+};
+/**
+ * The leading `<!-- @summary -->` comment, which the description above already
+ * carries. It is how an example declares its own one-liner to the analyzer, so
+ * it belongs in the file and not a second time in the prose beside it.
+ */
+const withoutSummary = (html) => html.replace(/^<!--\s*@summary[\s\S]*?-->\n*/, '');
+/** One family's examples, as the markdown a reader or an agent can run. */
+const shown = (depth, examples) => {
+    if (examples.length === 0) {
+        return [];
+    }
+    const lines = [`${'#'.repeat(depth)} Examples`, ''];
+    for (const example of examples) {
+        lines.push(`${'#'.repeat(depth + 1)} ${example.label}`, '');
+        if (example.description) {
+            lines.push(example.description, '');
+        }
+        lines.push('```html', withoutSummary(example.html), '```', '');
+        if (example.css) {
+            lines.push('```css', example.css, '```', '');
+        }
+    }
+    return lines;
+};
+/**
+ * A manifest, as the markdown reference for everything in it.
+ *
+ * The caller supplies the manifest and whatever preamble belongs above it, so
+ * the same renderer serves the whole-library document in `docs/` and a
+ * per-family page without either one knowing about the other.
+ *
+ * **A single family gets no heading naming it**, because the title already
+ * does: a document about the accordion should not say Accordion twice before
+ * its first sentence. More than one and the headings are what separate them.
+ */
+export const reference = (manifest, options = {}) => {
+    const front = options.frontmatter ?? [];
+    const lines = [
+        ...(front.length > 0
+            ? ['---', ...front.map(([key, value]) => `${key}: ${value}`), '---', '']
+            : []),
+        `# ${options.title ?? 'Component reference'}`,
+        '',
+        ...(options.lede ?? []),
+    ];
+    const wanted = options.families;
+    const families = referenceFamilies(manifest).filter((entry) => wanted === undefined || wanted.includes(entry.family));
+    /* Everything under a family heading sits one level deeper than it would in a
+       document that has no family heading to sit under. Without this a page about
+       one component opens at `###`, which is a heading level with nothing above
+       it and reads as a fragment of a larger file. */
+    const depth = families.length > 1 ? 3 : 2;
+    for (const { family, parts } of families) {
+        if (families.length > 1) {
+            lines.push(`## ${startCase(family)}`, '');
+        }
+        for (const { declaration, part } of parts) {
+            lines.push(...element(depth, declaration, part));
+        }
+        lines.push(...shown(depth, options.examples?.[family] ?? []));
+    }
+    return `${lines
+        .join('\n')
+        .replace(/\n{3,}/g, '\n\n')
+        .trimEnd()}\n`;
+};

package/dist/registry.d.ts

@@ -0,0 +1,89 @@
+/**
+ * Documentation registry for Helix.
+ *
+ * Docs are a package rather than a folder inside a site so that the docs are
+ * pinned to the version of the code they describe. A site renders this
+ * registry; it does not own it.
+ *
+ * **There is no version axis in here.** The package version is the version:
+ * `@fusion.dev/helix-docs@0.2.0` documents Helix 0.2.0, because every package in a
+ * domain moves in lockstep. A `versions` array beside that would be a second
+ * source of truth with nothing keeping the two in step, and the first time they
+ * disagreed the registry would win over the package that shipped it.
+ *
+ * A site serving several versions installs several versions, which is the
+ * mechanism npm already provides and the only one that cannot drift.
+ *
+ * **Nothing about a page is written here.** `pages.generated.ts` is derived
+ * from each file's frontmatter by `bun run docs`, because the frontmatter is
+ * what a `.md` consumer receives and a second copy would be a second source of
+ * truth. This module is the types and the reading of them; `sections.ts` is the
+ * spine that frontmatter has nowhere to live.
+ */
+import { docPages } from './pages.generated.js';
+import { type DocSection, docSections } from './sections.js';
+export interface DocPage {
+    /** One-line summary, used for nav tooltips and search results. */
+    description: string;
+    /**
+     * Position within a section that is a path.
+     *
+     * Absent everywhere else, where the order is pinned-entry-first and then
+     * alphabetical rather than something an author states.
+     */
+    order?: number;
+    /**
+     * Slug of the page this one sits under, for the one level of nesting that
+     * exists. Installation and its per-framework pages are the case.
+     */
+    parent?: string;
+    /**
+     * Whether this is its section's entry page, which sorts first and exempts
+     * itself from the alphabetical rule. At most one per section.
+     */
+    pinned?: boolean;
+    /** Title of the `DocSection` this belongs to. */
+    section: string;
+    /** Path segment, unique across the package. */
+    slug: string;
+    title: string;
+    /**
+     * Whether this page is the general answer rather than a named one.
+     *
+     * The mirror of `pinned`: that sorts a section's entry page first, this sorts
+     * a catch-all after the specific pages it is the alternative to. Installation
+     * is the case. Angular, React, Svelte and Vue are lookups and belong in the
+     * alphabet a reader scans; Other frameworks and Without a bundler answer
+     * "none of the above" and read as nonsense in the middle of it, which is
+     * where the alphabet was putting Other frameworks.
+     *
+     * Trailing pages stay alphabetical among themselves, so this states a rank
+     * and never a position.
+     */
+    trailing?: boolean;
+}
+/** One section of the sidebar, with the pages under it in render order. */
+export interface DocNavSection extends DocSection {
+    pages: DocNavPage[];
+}
+/** A page in the sidebar, with any children beneath it. */
+export interface DocNavPage extends DocPage {
+    children: DocPage[];
+}
+export type { DocSection };
+export { docPages as pages, docSections as sections };
+export declare const findPage: (slug: string) => DocPage | undefined;
+/**
+ * The whole sidebar: every declared section, its pages in render order, and
+ * each page's children beneath it.
+ *
+ * A section with no pages cannot appear, because `bun run check:docs` refuses
+ * to generate one. Children are alphabetical, because nesting exists for the
+ * per-framework installation pages and a reader picking their framework out of
+ * a list is looking one up rather than reading a sequence, and then the
+ * `trailing` ones, which are the pages that answer "none of the above" and
+ * which the alphabet was interleaving with the answers they follow from.
+ */
+export declare const navigation: () => DocNavSection[];
+/** Path to a page's MDX, relative to the package root. */
+export declare const contentPath: (page: DocPage) => string;