Reject invalid custom and arbitrary variants #8345
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Prior to this PR, you could create custom variants that generated rules with selectors we don't explicitly support.
For example:
Using that variant, you could write some HTML like this:
...which would generate this CSS:
Notice how that CSS doesn't even contain the
html:bg-black
class at all? This doesn't make any sense, because this CSS isn't actually going to be triggered by the use of that class in the browser, and makes it possible to cause a lot of bad side-effects. For example if you hadhtml:bg-black
,html:bg-white
, andhtml:bg-red-500
in your project, all 3 of them would be active at all times, regardless of whether one of those classes was used on the current page or not. Just makes no sense!So this PR explicitly disallows variant format strings that either don't contain the
&
placeholder, or aren't at-rules.When adding a custom variant with
addVariant
, invalid variants will throw an exception:When using arbitrary variants, the class is just ignored but no error is thrown (we never throw errors because of things we detect in your content files):
In the future we might re-purpose variants without the
&
placeholder for convenient shorthands, but we haven't decided exactly what we'd want to do there so introducing an explicit error in the meantime to effectively "reserve" it for future API.