Quartz Plugin Pipeline

Quartz’s three-stage content pipeline: every feature — from syntax highlighting to the graph view to RSS — is implemented as a plugin in one of three stages.

The Three Stages

1. Transformers

Map over individual Markdown files, modifying content or attaching metadata. Run first, before filtering.

Four extension points per transformer:

• textTransform — raw text manipulation before parsing
• markdownPlugins — remark plugins (Markdown AST)
• htmlPlugins — rehype plugins (HTML AST)
• externalResources — client-side CSS/JS dependencies

Examples: frontmatter parsing, LaTeX rendering, syntax highlighting, Obsidian-compatibility shims, callout processing.

2. Filters

Decide which transformed files get published. Each filter implements shouldPublish(file) → boolean.

Example: RemoveDrafts checks draft: true in frontmatter and excludes those files from output.

3. Emitters

Reduce over the full set of filtered files to produce output. Each emitter implements:

• emit() — writes output files, returns file paths
• partialEmit() — optional, for incremental builds
• getQuartzComponents() — declares which UI components the emitter uses

Examples: HTML page emitter, RSS feed emitter, sitemap emitter, graph data emitter.

Plugin Signature

All plugins follow the same factory pattern:

(opts?: Options) => PluginInstance

This lets every plugin accept optional configuration while keeping the pipeline uniform.

Why It Matters

The pipeline is why Quartz is highly customizable without being complex to operate. Defaults cover 95% of use cases; for the rest, you drop in a transformer or emitter without touching core code. The same mechanism that powers the built-in graph view is available for custom output formats.

See Also

• quartz — the full Quartz entity page
• context-distillation — another example of pipeline thinking applied to AI tooling