What's wrong
In Frontmatter/PropertyMerger.cs, a group of keys that share one canonical name is written back in one of two ways:
- Scalar values keep the original key:
target[originalKeys[0]] = firstValue (around line 165).
- List values go through
MergeArrayValues, which always writes target[canonicalKey] = ... (around line 189). This happens even when the group has only one key and nothing is merged.
So list properties get renamed during merging, whatever FrontmatterNaming the caller asked for. Renaming is meant to be NameStandardizer's job, and FrontmatterNaming.AsIs is meant to turn it off.
Failure scenario
Frontmatter.CombineFrontmatter(
"---\nsection:\n - news\nsummary: hi\n---\nBody\n",
FrontmatterNaming.AsIs, FrontmatterOrder.AsIs, FrontmatterMergeStrategy.Conservative);
- Actual: the output header contains
categories: [news].
- Same document with
section: news (a scalar): the key stays section.
- Expected: with AsIs naming, a key that isn't merged with anything keeps its name.
This matters for site generators where the key name has its own meaning. Hugo's section is one example. Content can silently move to a different taxonomy. keywords becomes tags and category becomes categories the same way.
I reproduced this with an MSTest test against the current main.
Suggested fix / acceptance criteria
- When
originalKeys.Count == 1, copy the key and value through unchanged, the same as the scalar branch does.
- When several list-valued keys really are merged, decide on one target key and use it consistently. Either use
originalKeys[0] to match the scalar branch, or use the canonical key only when naming is not AsIs.
- Add a test: a lone list property with AsIs naming keeps its key under every merge strategy.
What's wrong
In
Frontmatter/PropertyMerger.cs, a group of keys that share one canonical name is written back in one of two ways:target[originalKeys[0]] = firstValue(around line 165).MergeArrayValues, which always writestarget[canonicalKey] = ...(around line 189). This happens even when the group has only one key and nothing is merged.So list properties get renamed during merging, whatever
FrontmatterNamingthe caller asked for. Renaming is meant to beNameStandardizer's job, andFrontmatterNaming.AsIsis meant to turn it off.Failure scenario
categories: [news].section: news(a scalar): the key stayssection.This matters for site generators where the key name has its own meaning. Hugo's
sectionis one example. Content can silently move to a different taxonomy.keywordsbecomestagsandcategorybecomescategoriesthe same way.I reproduced this with an MSTest test against the current
main.Suggested fix / acceptance criteria
originalKeys.Count == 1, copy the key and value through unchanged, the same as the scalar branch does.originalKeys[0]to match the scalar branch, or use the canonical key only when naming is not AsIs.