fix: skip frontmatter when rewriting wiki links

[Showiix]

Summary

• Make rewriteWikiLinks() preserve YAML frontmatter when it receives a full markdown document.
• Continue rewriting wikilinks in the markdown body after the closing frontmatter delimiter.
• Add regression coverage for frontmatter wikilinks, body wikilinks, and indented --- inside YAML block scalars.

Scope

This is best described as a defensive correctness fix for the markdown rewrite helper.

On current main, the editor round-trip path strips YAML frontmatter in preprocessForEditor() before handing the body to Tiptap, then re-attaches it during serialization. Because of that, I do not want to claim confirmed current-main on-disk corruption through the normal editor/autosave path.

The issue this PR verifies is narrower: if rewriteWikiLinks() / prepareMarkdownSource() is called with a complete markdown document that includes YAML frontmatter, wikilinks inside the frontmatter should stay literal metadata rather than being rewritten as body links.

Related to #452.

Tests

• node test/test-markdown-preview.js
• npm test

[codeant-ai]

CodeAnt AI is reviewing your PR.

---

Thanks for using CodeAnt! 🎉

We're free for open-source projects. if you're enjoying it, help us grow by sharing.

Share on X ·
Reddit ·
LinkedIn

[coderabbitai]

📝 Walkthrough

Walkthrough

A bug fix modifies rewriteWikiLinks to detect and skip YAML frontmatter regions (delimited by ---) when rewriting wiki-link syntax, preventing corruption of YAML-quoted strings. Tests verify frontmatter wikilinks remain unchanged while body wikilinks are rewritten.

Changes

Cohort / File(s)	Summary
YAML Frontmatter Handling src/ui/file-preview/src/markdown/linking.ts	Add detection of YAML frontmatter when the first trimmed line is ---; preserve all lines inside the frontmatter (until the next ---) and bypass wiki-link rewriting and fence handling for that region. Outside frontmatter, existing fenced-code tracking and rewrite behavior remain.
Test Coverage test/test-markdown-preview.js	Add deterministic assertions to testWikiRewriteAndRendering ensuring wikilinks inside YAML frontmatter (including block-scalar cases) are not rewritten, while wikilinks in the body are rewritten with expected mcp-wiki metadata.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~12 minutes

Poem

A rabbit nudges dashes, soft and light, 🐇
Guarding frontmatter through the quiet night,
Wikilinks inside keep their cozy shells,
Body links still ring their tinkling bells,
Hopping on — all metadata well! ✨

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly and concisely describes the main change: skipping frontmatter when rewriting wiki links, which is the primary objective of the PR.
Linked Issues check	✅ Passed	The PR fully implements the proposed fix from issue #452: tracking frontmatter with a boolean flag, detecting the leading --- delimiter, preserving frontmatter content unchanged, and continuing to rewrite wiki links in the document body.
Out of Scope Changes check	✅ Passed	All changes are directly scoped to fixing the frontmatter issue: the linking.ts modification detects and preserves YAML frontmatter, and the test file adds regression tests for this specific behavior with no extraneous changes.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@src/ui/file-preview/src/markdown/linking.ts`:
- Around line 222-223: The frontmatter detection using trim() ===
FRONTMATTER_DELIMITER is too permissive (matches indented '---') so update the
checks to only match a delimiter at column 0: replace occurrences where you
compare line.trim() to FRONTMATTER_DELIMITER (the inFrontmatter computation and
the similar check at the later block) with a strict check such as line ===
FRONTMATTER_DELIMITER or a regex anchored to start like /^---\s*$/ to allow
optional trailing spaces but not leading indentation; update the
variables/expressions that compute inFrontmatter and the corresponding second
check (references: inFrontmatter, FRONTMATTER_DELIMITER, lines) accordingly.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 0f85b5c2-17bb-41d1-9ace-5a2f96b9d82e

📥 Commits

Reviewing files that changed from the base of the PR and between 6be424c and ceaf1ae.

📒 Files selected for processing (2)

• src/ui/file-preview/src/markdown/linking.ts
• test/test-markdown-preview.js

[codeant-ai]

Suggestion: The frontmatter close check uses trim(), so an indented line like --- (which is valid content inside YAML block scalars) is treated as a closing delimiter. That flips parsing out of frontmatter too early and starts rewriting wikilinks that are still inside frontmatter. Detect the closing delimiter only on an actual delimiter line (not whitespace-indented content). [logic error]

Severity Level: Major ⚠️

- ❌ Frontmatter wikilinks rewritten in preview for some YAML scalars.
- ⚠️ Markdown preview via renderMarkdown shows incorrect frontmatter links.

Steps of Reproduction ✅

1. Create a markdown note on disk whose first lines form YAML frontmatter with a block
scalar containing an indented `---`, for example:

   ---

   title: |

     intro text

     ---

   source_talk: "[[Frontmatter Link]]"

   ---

   (this shape is valid YAML frontmatter with the line ` ---` as scalar content).

2. Open this note in the markdown preview pipeline, which calls `renderMarkdown()` in
`src/ui/file-preview/src/components/markdown-renderer.ts:66-68`. That function passes the
full document text to `prepareMarkdownSource()` in
`src/ui/file-preview/src/markdown/parser.ts:53-55`.

3. `prepareMarkdownSource()` calls `rewriteWikiLinks(source)` in
`src/ui/file-preview/src/markdown/linking.ts:219-255`. Inside this function,
`inFrontmatter` is initially `true` because the first line is `'---'` (lines 220–223).

4. When the line ` ---` inside the block scalar is processed, `line.trim()` equals
`'---'`, so the condition at `linking.ts:231` (`if (line.trim() ===
FRONTMATTER_DELIMITER)`) fires, setting `inFrontmatter = false` at line 232. Subsequent
YAML frontmatter lines like `source_talk: "[[Frontmatter Link]]"` are now treated as body
content and passed to `replaceWikiLinksOutsideInlineCode()` (lines 249–253), causing
`[[Frontmatter Link]]` to be rewritten into a markdown link even though it is still inside
frontmatter.

Fix in Cursor | Fix in VSCode Claude

(Use Cmd/Ctrl + Click for best experience)

Prompt for AI Agent 🤖

This is a comment left during a code review.

**Path:** src/ui/file-preview/src/markdown/linking.ts
**Line:** 231:232
**Comment:**
	*Logic Error: The frontmatter close check uses `trim()`, so an indented line like `  ---` (which is valid content inside YAML block scalars) is treated as a closing delimiter. That flips parsing out of frontmatter too early and starts rewriting wikilinks that are still inside frontmatter. Detect the closing delimiter only on an actual delimiter line (not whitespace-indented content).

Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix

👍 | 👎

[codeant-ai]

CodeAnt AI finished reviewing your PR.

[edgarsskore]

Hello @Showiix!
Thanks for the PR. I tested this locally and want to clarify the actual impact/repro.

From what I can see on current main:

• read_file returns the raw markdown unchanged.
• The file on disk is not rewritten.
• Since v0.2.40, the current markdown editor/preview path strips YAML frontmatter before handing content to Tiptap/preview, then re-attaches it during serialization.
• Because of that, I could not reproduce visible frontmatter link corruption through the normal file preview UI.
• I can reproduce the issue only by calling rewriteWikiLinks() / prepareMarkdownSource() directly on a full markdown document that includes frontmatter, or by temporarily disabling the existing frontmatter-stripping logic.

So this looks valid as a defensive correctness fix for rewriteWikiLinks() when called on a full markdown document, but I’m not yet sure it is a current user-facing preview/file-corruption bug.

Could you clarify the original repro steps for the issue?
Specifically:

• Which user action triggers the bad rewrite in the current app?
• Does the rewritten frontmatter ever get saved back to disk?
• Is the issue visible in preview only, copy output, editor round-trip, or another path?

[Showiix]

Thanks for checking this locally. You're right, and sorry for overstating the impact in the original description.

I re-checked the current main path and I agree that I can't point to a normal editor/autosave flow that writes the rewritten frontmatter back to disk. Since v0.2.40, preprocessForEditor() strips YAML frontmatter before sending the body through Tiptap and re-attaches it during serialization, so that path looks protected.

The narrower thing I can still verify is at the helper level: when rewriteWikiLinks() / prepareMarkdownSource() is called with a complete markdown document, it rewrites wikilinks inside YAML frontmatter as if they were body content. Given that the helper already avoids rewriting fenced code blocks, I think keeping frontmatter literal is still the right behavior, but I agree this should be framed as a defensive correctness fix rather than confirmed current file corruption.

To answer your questions directly:

• Current user action: I can't currently identify a normal current-main editor/autosave action that writes this back to disk.
• Saved back to disk: I can't reproduce that on current main; the editor round-trip path appears protected by the frontmatter stripping.
• Visible surface: the verified issue is direct rewriteWikiLinks() / prepareMarkdownSource() output on a full markdown document. Preview/copy/render helpers still go through prepareMarkdownSource(), so I would describe this as guarding full-document renderer/helper inputs.

I updated the PR description to reflect that narrower scope.