mProjectsCode / mProjectsCode/obsidian-meta-bind-plugin

"Bake to Static Markdown" command to resolve VIEW/INPUT fields for external export tools

Open
#659 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

feature request
Dominant language
TypeScript
Stars
1k
Forks
86
PR merge metrics
No merged PRs in 30d

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 value
  • VIEW[{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 string
  • INPUT[...] / 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.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

No files, tests, or entry points are named. Start by tracing the existing VIEW and INPUT resolution logic and command handling, then define the export path and output mode; done means static Markdown resolves the listed field types and supports the proposed in-place, parallel-file, or clipboard workflows.

Written by the indexing model from the issue text.

Assessment

Tech stack
markdown, typescript
Domain
content, tooling
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
38/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.