Provide a "safelist" of sorts while having no-arbitrary-values set to "error"

[JGhignatti]

Hi,

> The problem + context

I'm the tech lead for a company that has a monorepo with many apps. Since updating to Tailwind v3 we've decided not to use arbitrary values cause we have a well defined Design System and allowing classes like bg-[#<my-random-color>] goes against the "well defined Deisgn System".
An oral contract or written documentation about not using arbitrary values for things that the Design System enforces is not enough for some of our developers, so I've then added this plugin to our repo and it's been keeping us safe. The only downside is that it disallows (as expected so far) classes that could be of use, without breaking our Design System, for example: grid-cols-[auto_minmax(0,1fr)].

> Proposed solution

A proposed solution would be to add a safelist for classes that could use arbitrary values, for example:

"tailwindcss/no-arbitrary-value": ["error", {
  "safelist": ["grid-cols", "w", "h"]
}]

would allow classes like:

• grid-cols-[auto_minmax(0,1fr)]
• w-[173px]
• h-[3px]
  that don't break our Design System.

The proposed solution has the downside that adding to the safe list, for example, text, would allow classes that change both the size and color of texts, for example text-[#ff0000] text-[18px] (please check the Additional context as well), but, just like enabling the no-arbitrary-values is a tradeoff, adding "classes" to the safelist would be one as well 🤷‍♂️.

The implementation seems easy to achieve (easier than both issues mentioned in the Additional context).

> Describe alternatives you've considered

That are in-house solutions that would allow us to keep no-arbitrary-values set to error, but achieve the grid-cols-[auto_minmax(0,1fr)], for example, but they would make us write our own CSS definitions, which is something we tried to run away from when adopting Tailwind.

> Additional context

Please note that both my motivations and the final results are different from #175 . I believe that what I'm proposing can be implemented without removing the possibility of later implementing the mentioned issue.

Please also note that this was similarly proposed in #247 , but, for the mentioned issue, the proposed solution would infer two things I consider a problem:

• The plugin would be able to categorize all classes and keep up to date with further Tailwind classes additions and keeping categorizing every class;
• The plugin would be able to distinguish between, for example, text-[#ff0000] and text-[18px], while one would be added to a "color" category, the other should be added to some other "text-size" category of sorts.

Worth mentioning: Tailwind has a safelist. Not the same at all, but we could follow the pattern, instead of other proposed solutions.

[JGhignatti]

Before posting this issue I thought about it being either a "safelist", as I presented, or a "un-safelist" (?), meaning that instead of adding classes that you'd allow arbitrary values, you'd addthe classes where it was supposed to either throw the error or warning.
As you can see in the message above, I thought that a "safelist" made more sense, cause providing the list of ok "classes" was better than providing the long list of blocked "classes", but just now I remebered about Arbitrary variants and how it'd be nice to allow them as well, not only the classes that "don't break my Design System", as I mentioned.

Providing a "un-safelist" would make Arbitrary variants work out of the box, but I don't think the tradeoff is fair. So a way of saying to the rule that Arbitrary variants is ok would be required.
This seems easily achievable and not an issue for the solution I presented, it's just a matter of considering all cases and making the right changes.

If I missed something, like the Arbitrary variants, please let me know and we can discuss if the proposed solution still stands.

[ginasummation]

Hi! my company also needs something like this, thought a regex whitelist would be sufficient for us, I can do a PR with the regex whitelist method

[ginasummation]

@francoismassart could you take a look? happy to discuss/help implement a solution!

[third774]

Same here, this would be tremendously helpful. I'd go so far as to say that for grid-rows-[.*] and grid-cols-[.*] (and probably some others) the default should be to have them on the allow list, but would understand why that may never happen.