Ensure custom variants can be used via @variant in addBase#20247
Conversation
We apparently handle it later already as expected. Additionally, this would actually introduce a bug for custom variants because this is substituted immediately instead of after resolving values.
Confidence Score: 5/5Safe to merge — the change is minimal and targeted, and the global substitution pass already handles @variant for the rest of the AST. The fix removes a single redundant early call to No files require special attention. Reviews (2): Last reviewed commit: "update changelog" | Re-trigger Greptile |
|
Caution Review failedThe pull request is closed. ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
WalkthroughIn 🚥 Pre-merge checks | ✅ 4✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. Comment |
This PR doesn't fix any issues, but it does add an integration test (as a regression test) to make sure that `@variant` with default variants and custom variants can be used inside of JS based plugin APIs. In Tailwind CSS v4.3.1 we introduced a PR that handles `@variant` in the `addBase` Plugin API (#19480). This was a bit of an older PR, but the tests made sense, so it was merged. However, by introducing that PR, we introduced a bug that the `@variant` was handled too early. If you added custom variants later _and_ used it in the `addBase`, then you would get an error since the variant isn't available (yet). That issue was fixed by #20247 Now the question remains, why did we even have the original PR when it already worked? The use case we had was using `@variant` as part of the `@tailwindcss/typography` plugin configuration for one of our templates. I was indeed able to reproduce the issue where `@variant lg` was seen in the output CSS file. Turns out that this template was using `@tailwindcss/typography` + `@variant` in the configuration, but it was also using Tailwind CSS v4.1.15. Upgrading to the latest version automagically fixed the issue we had. This is also the behavior you can see in the integration test. The correct behavior was introduced in an even older PR #19263 All that said, everything should work in the next release related to `@variant` usages inside JS based APIs. **Tiny improvement** While debugging what's going on, I noticed that we looped over the AST to get some nodes out and we did that twice. This PR also improves that by re-using the same list of nodes instead of computing it twice. This won't have a huge impact, but it happened while compiling every single utility which is not ideal. ## Test plan 1. All tests should pass 2. I can't see `@variant` in the output CSS file Input: <img width="655" height="323" alt="image" src="https://github.com/user-attachments/assets/20c8d524-3575-488c-b0c0-5c4669f37dc7" /> Before: <img width="477" height="175" alt="image" src="https://github.com/user-attachments/assets/045e2086-1d4b-487c-96ff-676351412935" /> After: <img width="484" height="175" alt="image" src="https://github.com/user-attachments/assets/24d950b1-7c28-40f8-96bc-81b38be0e7a3" />
This PR fixes an issue where
@variantinsideaddBaseis being used with a custom variant.The issue is that we substitute the
@variantcalls immediately when we call theaddBasefunction. That means that variants that aren't processed yet will error out.This is a regression, because this used to work in Tailwind CSS v4.3.0 and started failing in Tailwind CSS v4.3.1.
Test plan