bug npm run dev --turbo compiling material-tailwind error globals.css

[metacop]

Link to the code that reproduces this issue

https://github.com/metacop/materialtailwindbug.git

To Reproduce

there is a bug when compiling the project with --turbo. but without turbo it works, i am installing the material package tailwind 3v beta following these instructions.

when running with --turbo

but without --turbo

I don't know if more tests are needed for the turbo to work at 100%.

I uploaded the repository there is only 1 extra package when I run npx create-next-app.

"@material-tailwind/react": "^3.0.0-beta.23",

globals.css

page.tsx

layout.tsx

I feel this happens when we change the configuration of tailwind.config.ts, rather we change the bases of tailwinds.

Current vs. Expected behavior

xxxx

Provide environment information

Operating System:
  Platform: win32
  Arch: x64
  Version: Windows 10 Pro
  Available memory (MB): 31702
  Available CPU cores: 24
Binaries:
  Node: 21.7.3
  npm: N/A
  Yarn: N/A
  pnpm: N/A
Relevant Packages:
  next: 15.0.0 // Latest available version is detected (15.0.0).
  eslint-config-next: 15.0.0
  react: 19.0.0-rc-65a56d0e-20241020
  react-dom: 19.0.0-rc-65a56d0e-20241020
  typescript: 5.6.3
Next.js Config:
  output: N/A

Which area(s) are affected? (Select all that apply)

Turbopack, Webpack

Which stage(s) are affected? (Select all that apply)

next dev (local)

Additional context

No response

[samcx]

@metacop The css parser with Turbopack is stricter than with webpack. This is highlighting a bug in your own application, previously that selector would be ignored by the parser causing unexpected behavior.

[metacop]

@metacop The css parser with Turbopack is stricter than with webpack. This is highlighting a bug in your own application, previously that selector would be ignored by the parser causing unexpected behavior.

Is there a flag to not be strict or less strict with the css parser?

[timneutkens]

There is no flag to change the parsing, this is intentional to make sure broken CSS causes a compiler error given that otherwise it gets ignored in the browser making it fail at runtime.

I've reached out to @robinmalfait from Tailwind to figure out in what case Tailwind generates such a selector, your application seems to be using some way to create arbitrary selectors.

[timneutkens]

Robin's reply (sharing with their permission):

It is generated by Tailwind CSS because they wrote something like [&_data-slot=icon]:h-5 , in this case the value in the square brackets before the : means that it is an "arbitrary variant". Essentially it allows you to write a raw CSS selector as an escape hatch if some feature in Tailwind CSS is not supported.The issue is that they want to write this instead [&[data-slot=icon]]:h-5  because the first set of [] indicate that it is an arbitrary variant, the second set of [] is the actual attribute selector.This now produces the expected output of:

.\[\&\[data-slot\=icon\]\]\:h-5[data-slot="icon"] {
  height: 1.25rem; /* 20px */
} 

To go a step further, we do have data-* variants in Tailwind CSS so this can be simplified to just data-[slot=icon]:h-5.

That said, I'll track this internally to make sure we don't generate it in the first place.

[metacop]

Robin's reply (sharing with their permission):

It is generated by Tailwind CSS because they wrote something like [&_data-slot=icon]:h-5 , in this case the value in the square brackets before the : means that it is an "arbitrary variant". Essentially it allows you to write a raw CSS selector as an escape hatch if some feature in Tailwind CSS is not supported.The issue is that they want to write this instead [&[data-slot=icon]]:h-5  because the first set of [] indicate that it is an arbitrary variant, the second set of [] is the actual attribute selector.This now produces the expected output of:

.\[\&\[data-slot\=icon\]\]\:h-5[data-slot="icon"] {
  height: 1.25rem; /* 20px */
} 

To go a step further, we do have data-* variants in Tailwind CSS so this can be simplified to just data-[slot=icon]:h-5.

That said, I'll track this internally to make sure we don't generate it in the first place.

so if it comes from tailwind they should adjust it?. or vercel?. i agree that --turbo is strict with the generated css. but this prevents to lift the project. what should i do then if it is not a bug from vercel? nothing?