Handle legacy key behavior in theme-driven suggestions for @utility#17733
Handle legacy key behavior in theme-driven suggestions for @utility#17733thecrypticace merged 4 commits intomainfrom
@utility#17733Conversation
559bc02 to
e786443
Compare
philipp-spiess
left a comment
There was a problem hiding this comment.
Makes sense to make this behave the same as the default spacing utilities but I wonder when we can remove that special-casing for underscore separators like --spacing-1_5 😬
Do you think this (=the special handling for _) can eventually be moved into the IntelliSense extensions? 🤔
|
@philipp-spiess oh… hmmm. I don't know. The main problem I see with moving it into IntelliSense is that we really only want this behavior for theme keys. If someone were to define a utility like this: @utility foo-2_5 { color: red; }IntelliSense wouldn't know enough to ignore the replacement for this one utility so it would get suggested as |
|
It would be nice to remove this behavior though since it was really only for backwards compatibility with the alpha/beta releases. Maybe this is something we can discuss and figure out a timeline if/when we can remove it. |
|
Yep totally makes sense. I wonder if in the future it would be helpful if a suggestion derrived from a theme key can also emit the used theme key variable somehow - could be fun for go-to-source or so or to find out when using a deprecated theme key 🤔 |
Fixes tailwindlabs/tailwindcss-intellisense#1328
The alpha and beta releases used
_in theme keys to represent a.. This meant we used--leading-1_5instead of--leading-1\.5to add utilities likeleading-1.5. We prefer the use of the escaped dot now but still want to make sure suggestions for the legacy key format still works as expected when surrounded by numbers.This is the same as #16433 but for
@utilitysince we apparently missed this when emitting suggestions for it