You know, that's interesting. I tend to avoid Tailwind discussion because I feel like I don't see enough opinions from people working full time on huge projects using it. Most of the time, it seems like the strongest opinions in favor come from folks who have only used it in toy apps, side projects, or completely greenfield small-to-medium applications.
There's nothing wrong with using it in that way, of course, or of thinking it's the best tool for the job in those scenarios. But for some reason I rarely see that caveat mentioned, and the idea of refactoring a legacy application to use it makes me queasy haha.
> But for some reason I rarely see that caveat mentioned, and the idea of refactoring a legacy application to use it makes me queasy haha.
Easiest way to check is to just add tailwind with PostCSS and the `@tailwind` directives and see what happens to your app. Unfortunately, if there's substantial CSS it will most likely be a disaster because the Tailwind reset will clobber the assumptions made by the previous CSS. It can be really hard to refactor custom styles when you can't see how they were supposed to look without running a separate older commit.
You can try disabling the CSS reset tailwind adds but then you'll have to chase bugs in the assumptions Tailwind makes so it's a bit of a catch 22. If it's a really large project with dozens of developers in its history, chances are there is already a custom CSS utility framework in place that uses the obvious formats like "p-2"/"px-2" for padding (with a different scale, yay!) and other naming collisions. You can however use the `@apply` directive to inline the Tailwind styles in the legacy classes to make it easier.
There's nothing wrong with using it in that way, of course, or of thinking it's the best tool for the job in those scenarios. But for some reason I rarely see that caveat mentioned, and the idea of refactoring a legacy application to use it makes me queasy haha.