Nest variants and configuration options inside theme

Is your feature request related to a problem? Please describe.

Currently, the Theme object is flat. We’re compliant with System UI Theme specification, so scales have to be flat, but Variants (and there are quite a lot of them), and options (similarly) don’t have to be, and they’re not as important as scales.

Right now we kind of enforce on the user to keep their theme object “in order” manually, with whitespaces, regions or manual sorting. Somebody with an ESLint rule sorting object keys will have a really bad time reading interweaved scales, variants and options.

Describe the solution you’d like

I think we could keep them nested under variants and options properties. Of course, we’d have deprecate the old API and support both scenarios for a while, what’s a bit annoying from maintenance perspective.

Describe alternatives you’ve considered

Leaving it as it is.

Additional context

We might have even more options in the near future.

---

@lachlanjc @atanasster @dcastil, what do you think?

[hasparus]

🚀 Issue was released in v0.8.0 🚀

[hasparus]

I think we should totally put Theme UI config in a separate object (options as you suggest, config, etc), since that’s not part of the Theme specification & it’s weird it’s just there alongside “content” rn.

Separate object would be IMO the most elegant, but I’d keep them inside theme.options, because it allows to read them on the type level in “strict mode”. They could affect how the types work. (e.g. options.strictMode.allowStrings: false or options.strictMode.scales: ['colors', 'space'])