Validate frontmatter (and tags in particular)

[jpmedley]

On the wiki adding standardized tags such as 'Interface', 'Method', 'Property' etc. was pretty foolproof. If a contributor typed even a part of a standard tag, a prompt would ensure that correct spelling and punctuation is used. This is not longer true, which opens the possibility of creating duplicate tags such as 'Property' and 'property'. Reviewers would reasonably think a single instance of one or the other were correct. Other variations 'PRoperty' could creep in through human error. I opened this issue because I corrected what I believe to be the first instance off this in mdn/content#31

Another solution would be to make grouping of pages under a tag case-insensitive. Given the nature of computer work, I can't prove that won't create an overloaded tag somewhere.

[peterbe]

pages under a tag case-insensitive.

Yes please! But it won't stop someone from typing proprety.

I went through the same problem with my Firebase app I'm hacking on. It's a document store so I basically rely on typing the same string exactly identical in multiple locations of the database. Sucks but everything as its trade-offs.

But how do you know what the valid tags are? Do you need to intimately know exactly what the relevant KS macro expects? I.e. it's "attribute" not "member". Does there exist a list somewhere?

We might want to transfer this issue to mdn/yari.

[peterbe]

By the way, we could easily validate slugs and use the Flaw system to highlight the ones we don't like. But I still don't understand how you're supposed to know which ones are valid in the first place?

We can also break this down and switch to case insensitivity first if you think that's smart.

[jpmedley]

I only intended to imply that we do it for certain known and previously standardized tags. Doing more than that is a longer discussion.

[peterbe]

Even that isn't trivial. E.g. you can only become a member being by being one of the other members :) Because that would require first traversing all existing documents to build up the set of allowed tag strings.

But there are other tricks we could consider such as a dedicated CLI tool that you manually execute once. It could produce a little report that lists each tags and how often they appear. If a tag is the same as most others but in an unusual case, it could be highlighted.

[jpmedley]

We already have a list of standard tags. All I'm advocating here duplicating functionality that we had when this was a wiki. It's worth duplicating because that functionality prevented a lot of pain and an enormous amount of technical debt.

[himanshugarg]

From https://github.com/mdn/yari/issues/7456

We might want to transfer this issue to mdn/yari.

[Rumyra]

I'm going to move this issue to yari (as that's where it should live) but I'm going to add the on-hold label. From what i understand we are only using tags for experimental, deprecated et al and if we're able to power that a different way (say from bcd) we should be able to remove them.

Having said that this issue reminds us to validate front matter as a whole.