Please fill out these Check-boxes
Is your Feature Request related to a Problem or Annoyance?
When exporting Obsidian notes to PDF or other formats via external tools (pandoc,
obsidian-export, static-site generators, CI pipelines), VIEW and INPUT fields
are passed through as raw syntax (e.g. `VIEW[{process_owner}][text]`)
because those tools have no access to Obsidian's rendering context. Every external
tool that wants correct output must independently re-implement Meta Bind's field
resolution logic, including expression evaluation, render-type handling, and YAML
frontmatter parsing. This leads to fragile, duplicated implementations that diverge
from the canonical behaviour as the plugin evolves.
Describe the Feature you'd like
A "Bake to Static Markdown" command (similar to
obsidian-dataview-serializer
for Dataview) that resolves all Meta Bind fields in a note against its current
frontmatter and writes a static snapshot: either in-place, to a parallel file,
or to the clipboard.
Concretely:
VIEW[{key}][text] → replaced with the plain-text frontmatter valueVIEW[{key}][text(renderMarkdown)] → replaced with the raw markdown value
(wikilinks, external links, etc. left intact for downstream tools)VIEW[{key}][date(YYYY-MM-DD)] → replaced with the formatted date stringINPUT[...] / BUTTON[...] → stripped or replaced with their current value
The command could be triggered manually ("Bake current file") or as a pre-export
hook. The output is valid, portable Markdown that any tool can process without
knowing anything about Meta Bind.
Alternatives
-
Official pandoc Lua filter: The maintainer publishes a .lua filter that
reads pandoc's metadata block (frontmatter is already available there) and
substitutes VIEW fields. Users pass --lua-filter=meta-bind.lua and get clean
output. Narrower scope than the bake command (pandoc only), but very low
maintenance burden.
-
Standalone resolver package: A small, dependency-free npm/JS module that
takes markdown content + a frontmatter object and returns resolved content.
External tools import it instead of re-implementing the logic. Higher
maintenance surface than either option above.
Additional Context
The Dataview Serializer plugin is a direct precedent: it runs inside Obsidian,
evaluates Dataview queries, and writes static Markdown back to the vault. The
same pattern applied to Meta Bind would immediately unblock export workflows for
pandoc, WeasyPrint, Hugo, Quarto, and any other tool that processes Markdown
outside Obsidian.
Research confirms there is currently no supported path to obtain fully-rendered
Meta Bind output outside the Obsidian Electron context (no headless mode, no
CLI, no existing Lua filter). A bake command would close that gap for the entire
ecosystem with a single, maintainer-owned implementation.
Please fill out these Check-boxes
Is your Feature Request related to a Problem or Annoyance?
When exporting Obsidian notes to PDF or other formats via external tools (pandoc,
obsidian-export, static-site generators, CI pipelines),
VIEWandINPUTfieldsare passed through as raw syntax (e.g.
`VIEW[{process_owner}][text]`)because those tools have no access to Obsidian's rendering context. Every external
tool that wants correct output must independently re-implement Meta Bind's field
resolution logic, including expression evaluation, render-type handling, and YAML
frontmatter parsing. This leads to fragile, duplicated implementations that diverge
from the canonical behaviour as the plugin evolves.
Describe the Feature you'd like
A "Bake to Static Markdown" command (similar to
obsidian-dataview-serializer
for Dataview) that resolves all Meta Bind fields in a note against its current
frontmatter and writes a static snapshot: either in-place, to a parallel file,
or to the clipboard.
Concretely:
VIEW[{key}][text]→ replaced with the plain-text frontmatter valueVIEW[{key}][text(renderMarkdown)]→ replaced with the raw markdown value(wikilinks, external links, etc. left intact for downstream tools)
VIEW[{key}][date(YYYY-MM-DD)]→ replaced with the formatted date stringINPUT[...]/BUTTON[...]→ stripped or replaced with their current valueThe command could be triggered manually ("Bake current file") or as a pre-export
hook. The output is valid, portable Markdown that any tool can process without
knowing anything about Meta Bind.
Alternatives
Official pandoc Lua filter: The maintainer publishes a
.luafilter thatreads pandoc's metadata block (frontmatter is already available there) and
substitutes VIEW fields. Users pass
--lua-filter=meta-bind.luaand get cleanoutput. Narrower scope than the bake command (pandoc only), but very low
maintenance burden.
Standalone resolver package: A small, dependency-free npm/JS module that
takes markdown content + a frontmatter object and returns resolved content.
External tools import it instead of re-implementing the logic. Higher
maintenance surface than either option above.
Additional Context
The Dataview Serializer plugin is a direct precedent: it runs inside Obsidian,
evaluates Dataview queries, and writes static Markdown back to the vault. The
same pattern applied to Meta Bind would immediately unblock export workflows for
pandoc, WeasyPrint, Hugo, Quarto, and any other tool that processes Markdown
outside Obsidian.
Research confirms there is currently no supported path to obtain fully-rendered
Meta Bind output outside the Obsidian Electron context (no headless mode, no
CLI, no existing Lua filter). A bake command would close that gap for the entire
ecosystem with a single, maintainer-owned implementation.