Fix edit range being incorrect when utilities contain variants (#1480)

Fixes #1479

This is the result of a parsing issue inside core which causes us to
make incorrect assumptions. See
tailwindlabs/tailwindcss#19172

The tl;dr of how this bug happened:
1. We see `hover:bg-[` and each "part" gets tested
2. To test each part we compile `{part}:[color:red]`
3. We test `hover` and it passes — awesome ✅ 
4. We test `bg-[` and it passes — bad ❌
5. This is because it got turned into `bg-[:[color:red]` and was
incorrectly parsed as a valid utility. This is fixed in Tailwind CSS
v4.1.16

This meant that the start position was *after* the end position for a
completion's edit range because it assumed there was a separator (`:`)
after the `bg-[` part when there is not.

We'll work around this for old versions. As mentioned new Tailwind CSS
versions will handle this appropriately.

Author: thecrypticace

packages/tailwindcss-language-service/src/util/getVariantsFromClassName.ts

@@ -20,8 +20,6 @@ export function getVariantsFromClassName(
     return { variants: [], offset: 0 }
   }
 
-  parts = parts.filter(Boolean)
-
   function isValidVariant(part: string) {
     if (allVariants.includes(part)) {
       return true
@@ -60,11 +58,36 @@ export function getVariantsFromClassName(
   let offset = 0
   let variants = new Set<string>()
 
-  for (let part of parts) {
+  for (let [index, part] of parts.entries()) {
+    // If we see an empty variant it's because:
+    //
+    // - The string contains consecutive top-level separators, e.g.
+    //   hover::flex
+    // - The string *ends* with a `:` which is a signal that the variant is done
+    //   and more should be suggested
+
+    // The first case isn't a valid class, partial or otherwise. The second one
+    // *is* valid because a user is probably in the middle of typing a utility.
+    //
+    // In both situations a `break` is sufficient to signal that the remainder
+    // of the string should be ignored when determining variants.
+    if (part === '') break
     if (!isValidVariant(part)) break
 
     variants.add(part)
-    offset += part.length + state.separator!.length
+
+    offset += part.length
+
+    // All variants must be succeeded by the separator (`:`) when used in a
+    // utility. However, Tailwind CSS <= v4.1.15 has a bug where we consider
+    // `bg-[` valid because we try to compile `bg-[:[color:red]` which in turn
+    // parses as a valid class when it obviously is not.
+    //
+    // To combat this we've done two things:
+    // - Add the offset to all variants *except* the last one
+    // - Allow an empty string in the last position to account for situations
+    //   where a utility name is currently being typed (e.g. `hover:`)
+    offset += index < parts.length - 1 ? state.separator!.length : 0
   }
 
   return { variants: Array.from(variants), offset }

packages/vscode-tailwindcss/CHANGELOG.md

@@ -4,6 +4,7 @@
 
 - Offload content detection to separate process ([#1471](https://github.com/tailwindlabs/tailwindcss-intellisense/pull/1471))
 - Suggest canonical classes when pixels and rem values match based on the root font size ([#1476](https://github.com/tailwindlabs/tailwindcss-intellisense/pull/1476))
+- Fix completion edit range being incorrect when part before cursor ends with `-[` ([#1480](https://github.com/tailwindlabs/tailwindcss-intellisense/pull/1480))
 
 ## 0.14.28