Keep tailwind.config.js, revert css configuration, it’s a terrible idea!

[remorses]

v4 idea to use a css file to configure tailwind is terrible, it means incredible pain for existing tailwind developers that will have to learn a completely new way to configure projects for no reason

there is no way to discover the configuration syntax without reading the docs, while using a js file you can rely in your IDE auto complete

the configuration will start getting split into multiple css file and it will become impossible to reason about it, know where it is

I like the idea of using CSS variables for tokens, that’s all, all the other configuration is a TERRIBLE IDEA

How do you even come up with this syntax?

@import "tailwindcss" source("../src");
@import "tailwindcss/theme" layer(theme);
@plugin "@tailwindcss/typography";
@variant dark (&:where(.dark, .dark *));

This is going to be worse than ESM

PLEASE STOP! REVERT BEFORE ITS TOO LATE!

[leo-petrucci]

I'd like to at least have the option to keep both.

I have a set of shared variables that can be imported into the current config or used for other CSS solutions. Without the config file I have no idea how that's going to work.

[adamwathan]

You would just import a shared CSS file.

[remorses]

This means changing thousands of projects to migrate the js config to a css file, which the migrator cli currently doesn’t do (and making it robust enough will be hard because of imports, expressions, etc)

In my opinion you should keep the current js config as the default, my assumption is that no one will migrate to the css one other than for theme variables

[leo-petrucci]

You would just import a shared CSS file.

But I'd then need to convert all my reusable Javascript variables to CSS and maintain two sources of truth.

I love Tailwind but forcing a CSS configuration makes absolutely no sense. What about people that generate their colors using libraries like polished?

[jonct]

Shout out to #15375 for a thoughtful, “Gallant” request. Written to start a productive conversation, not to preclude one.

Personally, looking at the direction of native CSS nesting and related standards — and finding meaningful browser support — I'm persuaded that full migration with gradual convergence is the correct path forward and should be unambiguously expressed as such.

But perhaps there are ways that the assistive tooling can be improved, and people's fears set more at ease about any time horizon. It will be interesting to see more community thoughts in this area.

Worst case: if “no one will migrate” then now's your chance to step up, fork 3.x, and demonstrate who'll follow whose vision.

For anyone committed to this cause: consider boosting ideas and arguments from #15375 as your starting point. Good luck!

[daniel-brenot-wbd]

The css configuration actually helps in some pretty huge ways you may not have considered.

With css based configuration, you can reference existing style systems you may have in your codebase. This is a huge win for adoption at my workplace and honestly would have been a nightmare to maintain with the js based version.

[remorses]

I agree on that for theme tokens but dark mode, content, plugins, presets and prefix should remain the the js config in my opinion

[daniel-brenot-wbd]

Why? Please provide some reasoning why this is bad with some concrete examples. I don't think anyone wants to listen to someone shouting that something is bad without examples of the issues it causes or the features the js version has that this doesn't.

[remorses]

You should give a good reasons to change something, not to keep it same as now.