Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reject invalid custom and arbitrary variants #8345

Merged
merged 4 commits into from May 14, 2022

Conversation

adamwathan
Copy link
Member

Prior to this PR, you could create custom variants that generated rules with selectors we don't explicitly support.

For example:

addVariant('html', 'html')

Using that variant, you could write some HTML like this:

<div class="html:bg-black">

...which would generate this CSS:

html {
  background-color: #000;
}

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 had html:bg-black, html:bg-white, and html: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:

addVariant('html', 'html')
// Throws an exception at build-time

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):

<div class="[html]:bg-black">

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.

@adamwathan adamwathan merged commit 7fa2a20 into master May 14, 2022
@adamwathan adamwathan deleted the reject-invalid-variants branch May 14, 2022 17:58
@cossssmin
Copy link
Contributor

Ah, saw this too late :(

Here's how I was using it, it's now breaking that plugin:

#8647

Any chance this could be turned into an option or something? 🤞

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants