Strict tokens by token type in config

[kyranjamie]

Currently, strictTokens is boolean across all token types.

I'd love an option to incrementally adopt strict tokens. Consider borderRadius & width. I feel it's quite common to have perhaps a set of only a few possible borderRadiuses, therefore it'd be great to force this to be strict.

Width, however, is much harder. Odd exceptions, custom images etc all might require non-tokenized values.

So, if we were able to pick and choose which token types are strict, we can likely add more typesafety, where right now teams likely often leave this setting off.

[astahmer]

there was a similar discussion on discord a few months ago

pasting the original post so it can be indexed:

---

freddie
— 06/21/2023 3:47 PM
I love the strictTokens config but sometimes I wish I could have "semi-strict".

Take for example any color property. With strictTokens set to false, it will suggest colours in our tokens but also every valid css colour by name which is very off putting. Ideally we could remove the default CSS ones from the type suggestions, but still allow arbritrary values or the colorPalette values!

Now let’s look into width: with strictTokens set to true, we can only choose from a pre-selected range of widths, but with it set to false we can do whatever we want. Sometimes I wish I could have strict tokens by token type.

I could see the strict tokens options being expanded from a simple boolean to something like:

{
...config,
tokenPolicies: {
  base: "strict",
  sizing: "relaxed",
  color: "semi-strict"
  }
}

---

also related, a way to use arbitrary values with strictTokens: #1001

[neolectron]

I do like the idea, one benefit I would see is about migrations.

About the "relax" by property :
I come from a package where we have a lot of CSS files which sometimes has values that aren't part of the panda-config.
Not all the properties use arbitrary values, for instance our colors are normalized, but not our margins.
Although we would like to go from non-strict to strict, I wouldn't fix the whole CSS in the codebase in one go.

Having granular control over which properties are strict or not would greatly reduce the cost of a migration to panda-css.

About the "semi-strict property :
Having something like "semi-strict" would allow properties that aren't from the panda-config but are not random strings either.
Semi strict would prevent something like display: foobar;, which is a benefit we had prior migrating to panda-css, and we would also appreciate to keep it.
Instead it when typing display: I would have all known valid properties like table | flex | grid | etc... without allowing any string.