[v4] Tailwind CLI high CPU on bad css

[dotfrag]

What version of Tailwind CSS are you using?

4.0.0-beta.2

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

Tailwind CLI.

What version of Node.js are you using?

v22.11.0

What browser are you using?

Doesn't matter.

What operating system are you using?

Linux.

Reproduction URL

Steps in README.md:

https://github.com/dotfrag/tailwind-issue-repro

Describe your issue

Repro steps in repo README.

With the following CSS:

@import 'tailwindcss';

@theme {
  --font-sans: "Inter";
}

The node process is idling at 0.x CPU.

Then if you introduce bad css:

@import 'tailwindcss';

@theme {
  --font-sans: "Inter", theme('fontFamily.sans');
}

The node process CPU usage skyrockets to 20% causing 70C+ temps.

The CPU usage does not go down when removing the bad code.

[jane3144fit]

This issue highlights an intriguing challenge with Tailwind CSS's handling of dynamic theme resolution. It seems like a perfect storm where CSS expectations collide with Tailwind's powerful but sensitive build process.

[philipp-spiess]

Hey! I looked into this in more detail last week, it seems like that there are two issues happening here:

1. The CLI will not recover from when one compilation process will ever run into an endless loop. I feel like this is reasonable, because that should ideally never happen and the only real way to guard against this would be to run the compile step in a worker thread so we can abort it which does not seem worth it.
2. The other issue is that the code you wrote creates an endless recursion. I think we should try to break that recursion but when I looked into how that happens, it does seem pretty hard without adding additional checks and slowing down the system. (the recursion happens implicitly because the CSS function returns a valid CSS that will recursively call other CSS functions as it should - but since we don't have a way to create an identity for that function we can't see that it is the same function. Maybe there could be something that counts the number of time such a replacement happens?) I did verify that this only occurs when using the legacy theme function with v3 style paths though. So given that this is not a widespread issue, I don't think it's a priority for us right now to fix this right now.

I'm happy to review a contribution that tires to fix this but will close this bug report as a won't fix for now.