validate front matter

[Fil]

• error on unparsable front matter
• validate data.sql shape, console warn if there is any issue
• validate all the options known today

we could validate more stuff in the future

closes #1005
(although I could not reproduce the same crashes)

I had fun making sql tables named '123' and 'a"b': it worked. I would definitely not recommend, though.

[Fil]

I've rebased this PR and added some sort of validation for all the expected fields. The story for toc is a bit complicated, since it gets merged with config.toc later on.

[mbostock]

I pushed a commit which takes this in a slightly different direction:

• Changes the MarkdownPage["data"] to the strongly-typed FrontMatter interface
• Adds missing fields to the FrontMatter interface (e.g., sidebar, style)
• Adds front matter normalization tests
• Removes obsolete downstream coercion e.g. in mergeToc and mergeStyle
• Removes warning logs/erroring in favor of deterministic normalization

The last part is in the spirit of HTML5, which is to say that the normalization is well-defined, regardless of whatever input types the user gives us, so we don’t really need to consider these as errors.

[mbostock]

Approving but disabled auto merge so you have a chance to review. 🙏

[Fil]

We still need to catch any YAMLException, otherwise the server crashes when the front matter in malformed (which happens quite a lot while you're editing it, for example when you forget a colon). This is why I was returning a fake structure with an error message—it could be a structure like {error: "malformed yaml"} instead.

[Fil]

I'm afraid this looks a bit overengineered, but it now does what I wanted: show a clean error message when front matter is invalid; crash on build.

[mbostock]

I don’t think we should error. We should just ignore the front matter. (Markdown and HTML in general don’t error for bad syntax — it just gets ignored.)

[Fil]

OK, this simplifies things a lot.

[mbostock]

I changed it so that if the front matter is invalid, it just gets treated as content so you can immediately see on the page that the front matter is broken. Also, this means we don’t need to log the buffer to the console, which I didn’t find useful anyway (since the buffer could be arbitrarily long — even the entire document — which meant that you can’t even see the error message in the console).

[Fil]

thanks!