Exports

Compile and share content from your Flint.

Purpose

Mesh notes are interconnected - they link freely, embed content from each other, and form a web of knowledge. But when you need to share that knowledge, you often need linear, self-contained documents.

The Exports module compiles your Mesh notes into portable artifacts. It resolves transclusions (expanding embedded content), rewrites wiki-links, strips frontmatter, and produces clean output files that can be shared with others or imported into other Flints.

Export Structure

Exports live in the Exports/ folder at the root of your Flint:

Exports/
├── Guide.md                      # Export manifest
├── Guide/                        # Built export folder
│   ├── E (NUU Flint) Index.md
│   ├── E (NUU Flint) Getting Started.md
│   ├── E (NUU Flint) Reference.md
│   └── _manifest.json
└── API.md                        # Another export manifest

Each export has two components:

Manifest file - A markdown file that defines what to export
Output folder - Created when you build the export, named after the manifest

Export Manifests

An export manifest is a markdown file in Exports/ that lists the notes to include. The manifest file name becomes the export name.

Basic Manifest

---
description: Complete user guide for Flint
---

# User Guide

This export contains the essential documentation.

[Getting Started](/getting-started)
[Core Concepts](/core-concepts)
[Command Reference](/command-reference)

The manifest can include any markdown content - headings, prose, explanations. The key elements are the wiki-links that reference notes to include.

Manifest Frontmatter

Manifests support these frontmatter fields:

Field	Description	Default
`description`	Brief description of the export	none
`depth`	How many link levels to follow. `1` = direct links only, `2` = links and their links, `-1` = unlimited	`1`

Depth Control

The depth field controls how deeply the exporter follows links:

---
description: Just the listed notes
depth: 1
---

[Note A](/note-a)
[Note B](/note-b)

With depth: 1, only Note A and Note B are exported. If Note A links to Note C, that link is rewritten but Note C is not included.

---
description: Listed notes and everything they reference
depth: -1
---

[Note A](/note-a)

With depth: -1, the exporter follows all links recursively, including every referenced note.

The `flint export` Command

List Exports

flint export list

Shows all export manifests and their build status:

Exports

  ● Guide (12 files)
  ○ API (not built)

Use 'flint export build <name>' to build an export.

Build an Export

Build a specific export:

flint export build Guide

Build all exports:

flint export build
flint export build --all

Building an export:

Reads the manifest file
Collects all referenced notes (respecting depth)
Expands embeds inline
Rewrites wiki-links with export prefixes
Strips frontmatter from all files
Writes output to the export folder
Generates _manifest.json

The build command also automatically removes stale export folders (those without a corresponding manifest file).

Check Export Status

flint export status

Shows build status for each export:

Export Status

  ✓ Guide - 12 files
  ○ API - not built

File Transformations

When notes are exported, several transformations are applied.

File Naming Convention

Exported files are prefixed with the Flint name:

E (Flint Name) Original Name.md

For example, a note called Getting Started.md from a Flint named NUU Flint becomes:

E (NUU Flint) Getting Started.md

The E prefix indicates an exported file. This naming ensures exported files are distinguishable when imported into other Flints.

Duplicate Name Handling

If multiple notes share the same base name (e.g., Tasks/README.md and Docs/README.md), the exporter disambiguates them by including the path:

E (NUU Flint) README (Mesh - Tasks).md
E (NUU Flint) README (Mesh - Docs).md

Wiki-Link Rewriting

Links are rewritten to reference the prefixed file names:

Source:

See [Getting Started](/getting-started) for details.

Exported:

See [Getting Started](/e-nuu-flint-getting-started) for details.

The original name is preserved as a display alias for readability.

Transclusion Expansion

Embeds (![...](/)) are expanded into blockquotes with the content inlined:

Source:

Here's an important concept:

![Key Insight](/key-insight)

Exported:

Here's an important concept:

> **Key Insight**
>
> The actual content from the Key Insight note goes here,
> formatted as a blockquote.

Circular embeds (where Note A embeds Note B which embeds Note A) are detected and replaced with a comment to prevent infinite loops.

Frontmatter Stripping

All frontmatter is removed from exported files. This produces cleaner output for sharing and ensures internal metadata (like UUIDs and tags) does not leak into exports.

The _manifest.json File

Each built export includes a _manifest.json file:

{
  "name": "Guide",
  "flint": "NUU Flint",
  "builtAt": "2025-01-16T10:30:00.000Z",
  "files": [
    "E (NUU Flint) Index.md",
    "E (NUU Flint) Getting Started.md",
    "E (NUU Flint) Core Concepts.md"
  ]
}

This manifest records:

name - The export name (from the manifest file)
flint - The source Flint name
builtAt - ISO timestamp of the build
files - List of all files in the export

The _manifest.json is used by the Imports module to understand what files belong to an export.

Use Cases

Create a Docs.md manifest that lists your user-facing documentation:

---
description: Public documentation for users
depth: 2
---

# Documentation Export

[Quick Start](/quick-start)
[User Guide](/user-guide)
[FAQ](/faq)
[Troubleshooting](/troubleshooting)

Build it and share the Docs/ folder with your team.

Publishing to a Website

Export your content, then process the markdown files with a static site generator. The clean, frontmatter-free output works well with tools like Astro, Next.js, or Hugo.

Create focused exports that other Flints can import:

---
description: Architecture overview for dependent projects
depth: 1
---

# Architecture Export

[System Architecture](/system-architecture)
[API Reference](/api-reference)
[Data Models](/data-models)

Other Flints can then import this bundle to have access to your architecture documentation.

Creating Snapshots

Export a point-in-time snapshot of your project state:

---
description: v2.0 release documentation snapshot
---

# v2.0 Release

[Release Notes v2.0](/release-notes-v2-0)
[Migration Guide v2.0](/migration-guide-v2-0)
[API Changes v2.0](/api-changes-v2-0)

Best Practices

Design exports for your audience. A guide for humans differs from a bundle for other Flints. Consider who will consume the export.

Use depth intentionally. depth: 1 creates focused exports with only listed notes. depth: -1 captures everything but can include more than expected.

Keep manifests updated. When you add notes to a documentation series, remember to add them to the relevant export manifest.

Test your exports. Read the compiled output. Broken links, missing context, and ordering issues only reveal themselves in the final artifact.

Use descriptive names. The manifest file name becomes the export folder name. Choose names that communicate purpose: API-Reference.md, User-Guide.md, Architecture.md.

Module - Mesh - Source content for exports
Module - Imports - Import exports from other Flints
Reference - CLI Commands - Full CLI reference

On this page