Skip to content

Conversation

@thecrypticace
Copy link
Contributor

@thecrypticace thecrypticace commented Oct 21, 2025

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.

@thecrypticace thecrypticace changed the title Fix variant offset calculation Fix edit range being incorrect when utilities contain variants Oct 21, 2025
Copy link
Member

@RobinMalfait RobinMalfait left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Surprised that this didn't always result in off-by-one errors the moment you have a variant 🤔

@thecrypticace thecrypticace marked this pull request as ready for review October 21, 2025 20:47
@thecrypticace thecrypticace merged commit 5d441b3 into main Oct 22, 2025
12 checks passed
@thecrypticace thecrypticace deleted the fix/issue-1479 branch October 22, 2025 10:13
thecrypticace added a commit to tailwindlabs/tailwindcss that referenced this pull request Oct 22, 2025
Fixes
tailwindlabs/tailwindcss-intellisense#1479

Maybe should close
tailwindlabs/tailwindcss-intellisense#1480 —
perhaps we can find a workaround there for older versions?

We're building up a class name in code to validate if something is a
valid variant: `{variant}:[color:red]`

if `{variant}` got replaced with `bg-[` then we'd produce
`bg-[:[color:red]` and this parsed as a valid candidate:
```
bg-[:[color:red]
^^                root: `bg`
   ^              data type: `` (empty string) — this should be invalid
     ^^^^^^^^^^   value: `[color:red`
```

The value isn't valid _but_ the syntax for arbitrary values is pretty
lax in core. Oxide already won't pick something like this up though so
no problem there. Only a problem for something like IntelliSense or
clients using the compile() API directly.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Invalid edit range on completion resolve response

3 participants