Rewriting a CRLF document (or an LF one on Windows) produces mixed line endings: header uses Environment.NewLine, body keeps the original

[matt-edmondson]

What's wrong

The parser accepts CRLF, LF and CR input, but every writer builds delimiters, the YAML join and the trailing newline from Environment.NewLine, while copying the body through verbatim:

• CombineFrontmatter — Frontmatter/Frontmatter.cs ~L116
• AddFrontmatter — ~L203
• ReplaceFrontmatter — ~L225
• RemoveFrontmatter — ~L245 (body.Trim() + Environment.NewLine)

Failure scenario (reproduced with an MSTest probe on Linux, current main)

Input: "---\r\ntitle: A\r\n---\r\n---\r\nauthor: B\r\n---\r\nline1\r\nline2\r\n"

• CombineFrontmatter → "---\ntitle: A\nauthor: B\n---\nline1\r\nline2\r\n" — LF header, CRLF body.
• ReplaceFrontmatter, RemoveFrontmatter, and AddFrontmatter("line1\r\nline2\r\n", …) trim the body and append Environment.NewLine, so the body itself ends up mixed: line1\r\nline2\n.
• On Windows the mirror happens: an LF document (the normal state of a git checkout with autocrlf=false or .gitattributes eol=lf) comes back with a CRLF header and final line.

Consequences: noisy whole-file diffs, .gitattributes/editorconfig end_of_line violations, and linters flagging mixed endings — for a library whose typical use is batch-rewriting files in a repo.

Suggested fix

Detect the input's newline once (first \r\n, \n or \r found; fall back to Environment.NewLine when the input has none) and use it for the delimiters, the YAML line join and the trailing newline; normalize the serialized YAML's line endings to match.

Acceptance criteria

• For CRLF input, all four writers emit only \r\n; for LF input, only \n — regardless of the host OS.
• Tests cover CRLF and LF inputs for CombineFrontmatter, AddFrontmatter, ReplaceFrontmatter, RemoveFrontmatter.

[matt-edmondson]

Triage

• Category: Bug
• Priority: Medium. Every writer mixes line endings: a CRLF document gets an LF header, and an LF document on Windows gets a CRLF header. The body can end up mixed too. The result is noisy whole-file diffs and .gitattributes and editorconfig violations, which matters because the typical use is batch-rewriting files in a repository. Content itself is not lost.
• Area / suggested assignee: CombineFrontmatter, AddFrontmatter, ReplaceFrontmatter and RemoveFrontmatter in Frontmatter/Frontmatter.cs. Owner: @matt-edmondson
• Duplicates / in progress: not a duplicate. It touches the same writer paths as ReplaceFrontmatter/RemoveFrontmatter/AddFrontmatter/ExtractBody strip the first body line's indentation, turning a leading indented code block into prose #146 (the body's first-line indentation is stripped) and A | block scalar loses its trailing newline when it is the last key in the frontmatter (and CombineFrontmatter rewrites it as >-) #153 (block scalar trailing newline), and as open PR Keep a thematic break directly under the header in the body #145 (keep a thematic break under the header). All four change how the body is trimmed and joined, so land them in sequence to avoid conflicts.
• Next step: detect the input's newline once, falling back to Environment.NewLine, and use it for the delimiters, the YAML join and the trailing newline. Normalize the serialized YAML to match. Add CRLF and LF tests for each of the four writers.

---

Generated by Claude Code