Add size to suggestCanonicalClasses for same h-x & y-x combo

[voffie]

To start with, I apologise if this is the wrong place to share this idea.

Idea
While using the latest v4 version of Tailwind, I got some warnings/tooltips that recommended I for example wrote py-1.75 instead of py-[7px]. I've also seen similar tooltips for other cases (can't think of all of them from the top of my head as I'm writing this).

However, I didn't see any tooltips for the size class. The main idea is that if the user writes w-x h-x, it could recommend that the user instead write size-x. This sheds some light on that specific "helper" class and lowers the number of classes the user has to write to achieve the same result.

I fully understand if this isn't a prioritized feature, and I just thought it could be a nice QOL on top of an already good system. If you need more info or have questions, just let me know, and I will try to answer as quickly as possible!

[DucMinhNe]

The reason you see warnings for py-[7px] -> py-1.75 but not for w-4 h-4 -> size-4 is that suggestCanonicalClasses in Tailwind CSS v4 is designed around 1-to-1 token canonicalization, rather than multi-token grouping or linting.

Here is why that distinction matters in practice:

1. 1-to-1 Normalization vs Cross-Token Analysis

suggestCanonicalClasses inspects individual utility tokens in isolation:

• Given an arbitrary value class like py-[7px], it checks if the value matches an existing theme spacing step (resolving to py-1.75).
• Given legacy syntax or aliases, it maps directly to the preferred canonical form.

Because this evaluation is strictly 1-to-1, it is fast, stateless, and completely safe to run without inspecting adjacent class names.

Suggesting size-4 from w-4 h-4, by contrast, requires N-to-1 cross-token AST analysis:

1. Checking that both w- and h- share the exact same spacing value.
2. Comparing variants: md:w-4 md:h-4 can safely merge into md:size-4, but asymmetric variants like hover:w-4 focus:h-4 or w-4 hover:h-4 must not be touched.
3. Component composition and override safety: In component libraries and utility-merging patterns (like tailwind-merge), developers sometimes deliberately keep w-4 and h-4 split so consumer props can override only one axis (w-4 h-4 ${customWidth}). Collapsing them to size-4 changes override precedence.

2. Where this fits best: Linter Rules

Because multi-class shorthand replacement is an opinionated refactoring rule rather than single-token normalization, this is typically handled by linters rather than the core language server's canonical suggester:

• eslint-plugin-tailwindcss: Well-suited for an AST rule (e.g. prefer-size-shorthand) that verifies matching variants and offers an automated fix.
• Language server refactorings: A code action / quick-fix ("Collapse to size-4") when hovering over matching dimensions.

It is definitely a great quality-of-life helper, and surfacing it as a dedicated lint diagnostic or quick-fix action would be very useful!

[voffie]

Alright, thanks for the answer! I can see how adding the checks to the root and not as a linter rule will add a lot of overhead and slow down performance quite a bit. Will look in the eslint project you talked about!

EDIT: Looked inside eslint-plugin-tailwindcss and it seems like they have implemented it already!