allow optional +

[dave-connors-3]

For any config, use patternProperties allow for an optional + at the start of the key name

closes #36

[joellabes]

@dave-connors-3 I think I tried doing this last year, and discovered that pattern-based columns prevent autocomplete from working in most systems, because the IDE doesn't know what it can sensibly offer up.

So I might be a buzzkill on this and suggest that we have to duplicate everything with and without pluses 😬 (or insist on people using the pluses? they are more correct, although since there's no equivalent to sqlfluff fix for a JSON Schema the migration would be painful for anyone trying to do that)

[dave-connors-3]

i am in accordance with your feedback! autocomplete and highlighting on both versions feels like a better overall experience for people

[dave-connors-3]

@joellabes ready for rereview!

[joellabes]

@dave-connors-3 here's some other thoughts, as I look at that big wall of copy-paste and grimace at the thought of keeping them in sync:

• could we script this in a GHA so that we only add the +ed version and it adds a +less variant?
• should we do everything as defs (this feels like the equivalent of having a dbt model whose only content is a one-line macro, a pattern that I dislike but is my least disliked pattern overall)
• both of the above?

[dave-connors-3]

@joellabes made the update we discussed -- for each config, there's now a reference in defs for the definition of that config, and then a plus and non-plus version that references that definition. Anything that already referenced a definition (like docs_config for example, was left alone, and the duplicated non-plus entry should point to the same definition.

[joellabes]

@dave-connors-3 this looks great! I have just added a CI test (you can see the results here, here and here if you'd like to see what the output is) to validate that every key exists with/without a plus, and that their contents are identical.

Strictly speaking, it is inefficient to validate that the objects are identical in both directions, but I have to check the keys have counterparts in both directions and decided that it didn't matter enough to optimise.

Therefore I've approved this but not merged it - you can make sure you're happy with my changes, and if you are then merge away!

[dave-connors-3]

thank you @joellabes