Change Request: Add JSON Frontmatter Support

[Pixel998]

Environment

ESLint version:
@eslint/markdown version:
Node version:
npm version:
Operating System:

What problem do you want to solve?

The Markdown plugin currently only supports YAML and TOML frontmatter formats. However, many popular static site generators and documentation tools already support JSON frontmatter, including Hugo, VitePress, 11ty and possibly others. I think adding JSON frontmatter support would improve compatibility with these widely-used tools.

What do you think is the correct solution?

Modify the frontmatter handling in markdown-language.js to support JSON format

Participation

• I am willing to submit a pull request for this change.

Additional comments

No response

[lumirlumir]

Thank you for the suggestion — it's definitely an interesting idea. While I understand that some major SSG frameworks do support JSON front matter, it's still relatively uncommon compared to YAML and TOML, which are more widely adopted and generally recommended in the Markdown ecosystem.

Before moving forward with this, I’d like to gather more feedback from other users to better understand the demand and potential use cases.

Also, I would like hear more opinions from @eslint/eslint-team

[nzakas]

It seems like mdast-util-frontmatter already supports JSON frontmatter. If it's just a one-line addition, then I think it's worth adding.

[lumirlumir]

Yes, I also found that adding this new feature wouldn’t be too complicated 👍

• https://github.com/syntax-tree/mdast-util-frontmatter/blob/d76616b88bdafdbbcd97247c4d3a8a41cc71ae48/test.js#L278-L290
• https://github.com/syntax-tree/mdast-util-frontmatter/blob/d76616b88bdafdbbcd97247c4d3a8a41cc71ae48/test.js#L422-L430

However, before proceeding and marking it as accepted, I want to discuss one more thing.

What delimiter should we use?

Hugo says:

{
    // json
}

VitePress says:

---
{
    // json
}
---

11ty says:

---json
{
    // json
}
---

YAML and TOML use an uniform convention, but JSON has a few different styles.

[nzakas]

Hugo doesn't seem to be very popular among Node.js developers (our target audience), so I think we can skip that for now.

Otherwise, looking at Vitepress vs. 11ty:
https://npmtrends.com/@11ty/eleventy-vs-vitepress

Maybe we can add two options?

1. json - Vitepress-style
2. json-11ty - Eleventy-style

[lumirlumir]

@nzakas

Oops, I found that Hugo is actually the most popular framework among those 😅

(Also, I think Hugo supports JavaScript users as well? https://gohugo.io/hugo-pipes/js/)

Since it’s based on Go, it might not have shown up clearly in npm trends.

https://jamstack.org/generators/

---

Then, json for Hugo, json-11ty for 11ty would be a better approach?

[nzakas]

That site doesn't show popularity, it just shows GitHub stars, which don't mean anything.

Regardless, I think json should be the Vitepress style because it matches the yaml and toml options we already have by looking for ---. That keeps the basic options consistent. If we want to add json-11ty and json-hugo, that's fine.

[lumirlumir]

@nzakas I understand. Thanks for your explanation.

In conclusion:

• json (VitePress style)

---
{
    // json
}
---

• json-11ty (11ty style)

---json
{
    // json
}
---

• json-hugo (Hugo style)

{
    // json
}

---

Marking it as accepted, since there’s consensus.

[Pixel998]

It'll be tough to get consistent behavior across all three JSON frontmatter styles. For example, with json-hugo ({fence: {open: '{', close: '}'}}) the value won't include the curly braces. However, for json ({fence: {open: '---', close: '---'}}) and json-11ty ({fence: {open: '---json', close: '---'}}), the JSON's own curly braces will remain in the value because they're treated as content, not part of the fence. I have also tried configuring json-11ty with {fence: {open: '---json\n{', close: '}\n---'}}, but mdast ignores this more complex fence definition.