Cannot override tailwind utilities.

[acalvino4]

What version of Tailwind CSS are you using?

v4.0.9

What build tool (or framework if it abstracts the build tool) are you using?

N/A - tw play

What version of Node.js are you using?

N/A - tw play

What browser are you using?

Brave

What operating system are you using?

MacOS

Reproduction URL

https://play.tailwindcss.com/4Nn2WwpPU3?file=css

Describe your issue

When I try to override a base tailwind class...

@import "tailwindcss";

@utility w-10 {
  width: 100px;
}

...it does not have any effect because in the output css, tailwind's generated utility comes later:

.w-10 {
  width: 100px;
}
.w-10 {
  width: calc(var(--spacing) * 10);
}

I would expect that any utility declarations I put after @import tailwindcss would override it.

Additionally, though it probably makes sense to list both of these in the output css file in dev, the production build should have this reduced to a single width declaration: .w-10{width:100px} (this works on the lightning css playground, hence my assumption). Instead I'm getting .w-10{width:100px;width:calc(var(--spacing)*10)}.

[philipp-spiess]

Yeah we had to make @utility add on top of the core utility for backward compatibility reasons. We've been thinking of ways to change that but that would probably mean some kind of new feature, so not something that we would classify as a GitHub issue unfortunately (hence I tried to migrate this issue to a discussion but GitHub won't let me right now...).

Can you elaborate what you mean with the lightning css playground? For me it's keeping both width values.

[acalvino4]

If what I'm asking for "would probably mean some kind of new feature", then I believe the topic of this discussion is essentially what I need (ability to disable core utilites), as it would deal both with the duplicate rules in css output and the css priority issue.

To me the simplest way (from a user standpoint, not necessarily implementation) to disable core features would be to just override them, and as evidenced by this bug report, my expectation was that this would just work. However, I understand the difficulties of implementation and maintaining backward compatibility may make that infeasible - if so, a separate way to explicitly disable certain utilities/features/classes is certainly a necessity (and, as others in the linked discussion have argued, is also a backwards compatibility concern).

As I think about it more, disabling core utilities is probably a better method than overriding, both bc explicit is better than implicit, and bc there may be situations where a team wants to disallow certain utilities but not replace them.

Whatever method is chosen to do this, it should be made possible to use from a plugin. My particular use case is that I'm trying to replace the default spacing scale with one that only allows spacing values from my design system.

As to the discrepancy we were seeing in lightningcss, turns out I had been using an over-simplified example that made a difference. It seems that difference is the use of custom properties, and I'm guessing that's something lightningcss doesn't collapse bc technically a custom property could be undefined, in which case the other rule would still apply.

[philipp-spiess]

Yeah, totally makes sense. We'll think through this, thank you!