Repository navigation
"Bake to Static Markdown" command to resolve VIEW/INPUT fields for external export tools #659
Description
Please fill out these Check-boxes
- I checked for existing similar feature requests
- I have read the docs and checked that the feature I am requesting is not already implemented
- My feature request consists of only one feature
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
.luafilter that
reads pandoc's metadata block (frontmatter is already available there) and
substitutes VIEW fields. Users pass--lua-filter=meta-bind.luaand 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.
Activity
mProjectsCode commentedon May 6, 2026
sort of duplicate of #287
alt-jero commentedon Oct 12, 2026
Also interested!
Especially for VIEW this would be handy.
I write reports in Obsidian and copy them into a work app, so I've been breaking my brain trying to find a way to do it where I can fill in the properties as front-matter or using form controls (Yay Meta Bind!) and have the report fill in from there.
VIEW is awesome for this, but it doesn't copy as markdown, which I do need, so for now I think I'm going to have to generate the markdown and render it in an editor input so I can copy it to clipboard. Or figure out how to do it with a button. Actually maybe I can do it with VIEWs by using them to generate markdown as text and then copy the text from view mode rather than edit mode...
I may have to use JS Engine for this at the moment though. We shall see. Looking forward to this feature potentially being implemented!
m13v commentedon Oct 13, 2026
the lua filter alternative ends up rebuilding the same logic it's supposed to replace, just in lua. pandoc parses every frontmatter string as markdown before the filter ever sees it, so a value like 'between $5 and $10' reaches the filter as inline math, not the raw text VIEW would print. then date(YYYY-MM-DD) formatting and any {a} + {b} expression need their own lua evaluator too. so it drifts from the plugin's real behaviour the same way the third-party tools already do. the bake command keeps one implementation.
brodyga45 commentedon Oct 20, 2026
For the report-copying workflow described here, which Meta Bind field types must survive in the first useful Markdown snapshot: VIEW text/date only, or also computed expressions and INPUT values?
I’m evaluating a small local snapshot add-on: keep the source note unchanged and generate a portable Markdown copy inside Obsidian, using Meta Bind’s own values/formatting rather than a separate Lua evaluator. API feasibility is still unverified.
Would that be useful enough to consider a source-included kit around US$29 once, or does an existing workaround already cover your reports? This is an unbuilt product idea; no order, payment or private report is being requested. A tiny invented example of the essential field types would be enough to scope a test.
Disclosure: AI-assisted product research for brodyga45.
Feasibility update, 20 Oct: I ran six synthetic core checks at commit
7d3f393341960b501057f9fe0f1d36deba020400, using Meta Bind’s own in-memory test harness. Raw currency text and intended Markdown stayed distinguishable, and the math result could be obtained without a metadata write by separating computation from mounting. A positive control using the normal mounted computed field wrote its bound value once. The proposedVIEW[...][date(YYYY-MM-DD)]syntax was rejected by the current validator. This proof uses protected implementation methods, so it is not an existing supported export API. The Obsidian application, full Markdown/Pandoc output and a finished add-on remain untested.mProjectsCode commentedon Oct 20, 2026
@brodyga45, please note that this plugin is licensed under GPL v3.0. So any derivative work that you build on top of this plugin must also be published under that same license.
brodyga45 commentedon Oct 20, 2026
Thanks for flagging this. Understood: any derivative I distribute must comply with GPLv3, including corresponding source, license text and preserved notices. I’m not proposing proprietary restrictions on Meta Bind-derived code. No derivative plug-in/package has been distributed; I’ve only shared the synthetic feasibility findings here. The kit remains an unbuilt idea, rather than a supported export API.