Source classes are not detected correctly when specified as `data-loading="addClass(opacity-50)"`

[gremo]

What version of Tailwind CSS are you using?

v4.1.18

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

https://github.com/SymfonyCasts/tailwind-bundle

What version of Node.js are you using?

N/A

What browser are you using?

Chrome

What operating system are you using?

Windows

Reproduction URL

N/A

Describe your issue

In Symfony live components, usually one defines the data-loading attribute with the addClass directive, like this:

<div data-loading="addClass(opacity-50)">
  <!-- -->
</div>

The source analysis mechanism for extracting CSS classes fails in this case, and the opacity-50 class is not added to the output.

[coderabbitai]

📝 CodeRabbit Plan Mode

Generate an implementation plan and prompts that you can use with your favorite coding agent.

• Create Plan

Examples

• Example 1
• Example 2

_{You can configure auto-planning by selecting labels in the issue_enrichment configuration.}

🔗 Similar Issues

Related Issues

• @source detection not working in a web components monorepo #18186
• Markdown class directive syntax not supported #18071
• Modifiers do not work with static classes #18145
• Tailwind 4.0.10 breaks class extraction from Maud templates in some contexts #18984

👤 Suggested Assignees

• taylorfsteele
• PhotonQuantum
• simjnd
• Princesseuh

---

🧪 Issue enrichment is currently in open beta.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord or schedule a call!

[thecrypticace]

I'd be concerned that trying to scan addClass(opacity-50) and extract opacity-50 might cause complications when classes themselves contain (…) (e.g. text-(--my-prop)).

Looking further at that syntax from Symfony Live Components we'd have to also know to treat | as a boundary character and not something that would be an invalid part of a utility name and thus shouldn't try matching again until we see a space, quote, or something like that.

Trying to shoehorn this into the general HTML parser too might be a bad idea. In HTML model(user.email)|delay|addClass(opacity-50) is a valid class name (just have to escape the selector correctly but it totally works: https://play.tailwindcss.com/pL0PMRtfo3?file=css) and we'd need a way to know when it's intended to be one and when it might not be and we can look "inside" the individual pieces.

We could perhaps do something for .twig files only if that's enough of a signal?

Will have to think on this one.

aside: I'm a bit surprised the syntax is addClass(opacity-50) and not addClass('opacity-50') (which would also "just work") 🤷‍♂️

[sanwalsulehri]

what if i can handle this