Styling seems off compared to comparable/working build using Vite

[phillipspc]

As best I can tell, the styling provided by this gem seems off compared to what it should be. I noticed this when attempting to use components from TailwindUI, where copy/pasting those components should produce the exact styling previewed there.

For reference here is a screenshot of an input from the TailwindUI site:

When I attempt to build that component in an app with the most basic/vanilla setup possible (ie. a new Rails 8 project with -css tailwind argument), I get this:

As a troubleshooting step, I setup the equivalent app using Vite as a build path instead of the tailwindcss-rails gem. Here's the output there:

As you can see, the build with Vite looks correct, while there are several styling problems with the build through tailwindcss-rails. Both apps look to be running the same version of Tailwind under the hood, so I can only assume that something is off with the configuration provided by this gem.

[flavorjones]

We have a related report in #441

I could use your help figuring out what's going on. There's no magic in this gem, it's just running the upstream tailwindcss CLI against the generated tailwind config. My guess at this point is that the CDN and Vite solutions provide plugins that the CLI does not. I don't know anything about Vite, so I would appreciate any insight you have.

[phillipspc]

@flavorjones thanks for that context. Would love to help in any way I can.

I don’t have much to contribute in terms of Vite expertise, this experiment was actually my first experience with it.

I’m starting to wonder if someone from the Tailwind team would be best equipped to answer the question of what’s gone off course here. They also mention this integration as an official one in their docs too so it seems to me they have some incentive for it to keep working properly.

I may try opening an issue there to see if that gets any traction.

[phillipspc]

@flavorjones Alright I opened this issue over at the tailwindcss repo and got some answers from Adam there.

Apparently TailwindUI does not expect the forms plugin to be installed and so there were some clashing styles. Because tailwindcss-rails comes with this and 2 other plugins by default, that's what's creating this discrepancy between its behavior and other build tools, in certain circumstances.

It looks like that decision dates way back to when DHH was building out this gem originally: commit

From Adam:

personally I don't think any of those plugins should be in there and enabled by default, that's not the same experience you get when you initialize a Tailwind project outside of Rails and we don't actually use any of those plugins on our own projects. Should be opt-in for sure 👍

I would also personally like to see these plugins dropped as the defaults, and would be happy to make that change, but I'll leave it up to you how to handle this!

[flavorjones]

@phillipspc Nice find, thank you so much for tracking down the answer.

I tend to agree that we should probably drop the default plugins (as well as the default "Inter" font, see #353). I'll also note that it doesn't look like the "forms" plugin changes the styling of the scaffold very much.

In the meantime, people who are affected can remove these plugins from their project's config/tailwind.config.js file.

I'll take a whack at a PR and we can solicit DHH's opinion there.

[flavorjones]

Hmm, actually, the forms do look different without the plugin, which is something Adam's response doesn't take into consideration: this gem is trying to make Rails have some sensible defaults out of the box, not just be a tailwind initializer.

[phillipspc]

this gem is trying to make Rails have some sensible defaults out of the box, not just be a tailwind initializer.

@flavorjones Respectfully, I'm a bit surprised by this response. For one, it seems at odds with how this gem was framed before:

There's no magic in this gem, it's just running the upstream tailwindcss CLI against the generated tailwind config

For another, I'm not really seeing that vision laid out anywhere in the readme, which in my opinion does give off the impression that this gem is an unopinionated initializer.

If Adam thinks these plugins should be opt-in, I think that deserves strong consideration. But if your decision is to keep things as-is, I think some small changes could go a long way to helping others not end up in this same spot:

1. Call this vision of "sensible defaults" out in the Readme
2. Consider having the install command be the place where users can opt in/out of this choice, which would also further highlight that the gem is doing something that deviates from the baseline.

Curious to hear your thoughts and happy to contribute towards any of these changes.

[flavorjones]

I'm still putting together the PR to remove the plugins. My comment was trying to frame the original decision to include default plugins, which I wasn't around for, and which I don't have strong opinions on anyway.

[flavorjones]

See #446