Preprocessing of frontmatter
See original GitHub issueIt would be cool to run some processing on front matter before it’s delivered thru layout props/and potentially stuff.
For example, I define my page descriptions in the front matter and i want to smartypants
these descriptions before they’re used in <meta>
tags and whatnot.
---
description: It's my description--I hope you enjoy the contents.
---
Should ultimately be transformed to
It’s my description—I hope you enjoy the contents.
If you pull a smartypants implementation into your code that’s extra that needs to be shipped to the browser when it could’ve been processed away at compile time.
There are a few other use cases for this, @pngwn noted that some want to put actual markdown inside the frontmatter too which would require similar considerations.
My proposed solution
Add a new mdsvex option that allows to to run custom transforms on the frontmatter before it’s delivered elsewhere.
mdsvex({
preprocessFrontMatter: ({key, value}) => { ... }
})
Open questions
- You might want different behavior for different kinds of files, so knowing which file is being preprocessed might be useful. How should this be passed?
- You also might want to reuse the parser you have defined with all of its plugins etc, to be run that over the value. This does not currently fit into the proposed solution.
Issue Analytics
- State:
- Created a year ago
- Comments:9 (2 by maintainers)
Top GitHub Comments
Oh Man, I should have read this earlier. Would save me a couple of hours. I was updating
yaml
in the tree but didn’t see any changes on the imported modules. Adding this data to vFile solved it.I can add docs somewhere if you’d like. This is a kinda implicit convention/API that I couldn’t grasp.
You can also write a custom remark plugin, the frontmatter data exists on the
vFile
and can be modified by plugins. Would still be nice to have a clean API for this in v1 (there will be no remark then).