Rails engine support

[flavorjones]

I wanted to start a discussion thread about support for Rails Engines and multiple Tailwind CSS files. This is an attempt to bring a few related conversations together and start to drive towards a clear understanding of the problem(s) people need solved and talk about potential solutions.

Context

There have been a few issues and pull requests around a similar set of problems. In chronological order:

• What's the 2.0 strategy for including styles seen in engines? #108
• Generator arguments do not work for engines #150
• https://stackoverflow.com/questions/71232601/how-to-use-tailwind-css-gem-in-a-rails-7-engine/
• Deploying multiple stylesheets #151
• Support multiple Tailwind css files in a project. #242

The topics from #108, #151, and #242 are related: how to support multiple CSS files, whether those are in engines/gems or elsewhere in the Rails application.

Issue #150 is slightly different and relates to full support for Rails engine generators. If we want to implement build-time support for Engines using tailwindcss, then we logically should implement generator support for Engines, too.

(The Stack Overflow thread touches on both topics.)

The problem space

Here's my first draft of articulating a problem statement (feedback welcome):

tailwindcss-rails should make it easy to write an Engine that uses Tailwind CSS.

The current tailwindcss-rails generator and its configuration both assume it's running in a top-level Rails application, and hardcodes some of those assumptions into, e.g., config/tailwind.config.js. The gem doesn't provide any ways to dynamically configure or extend this behavior.

As a result, people have fallen back on hacks like generating tailwind.config.js dynamically or forking out to bundler within tailwind.config.js to inject additional paths.

This problem statement doesn't explicitly include the "multiple Tailwind CSS files in an app" scenario from #242. In that discussion, @dhh gently pushed back on having multiple files in an app, which I think is healthy. But I suspect, if tailwindcss-rails provides a mechanism for building against assets in engines or gems, whatever mechanism we implement can be used by people to declare their separate Tailwind CSS files if they really want to do it.

The solution space

I think the broad strokes of how an engine integrates into railties are pretty well-known at this point, but broadly:

• the engine declares a dependency on the tailwindcss-rails gem
• the engine has its own tailwind config file
• which it registers in a Rails initializer, perhaps appending to config.tailwindcss_rails.config_files

Then, the gem's rake tasks tailwindcss:build and tailwindcss:watch, as well as the Puma plugin and/or the engine server hook from #347, would be extended to build multiple Tailwind CSS files.

We would also implement support for the plugin generator so that if an engine is created via rails plugin new --css tailwind then the above configuration is already in place.

Next steps

Heading into Rails Conf in about 10 days, I'm going to be at the Hack Day and would like to work on this there.

I'd love feedback from y'all on either the problem statement (did I miss a use case? does the problem statement presume too much about the shape of the solution? are there alternatives you'd like to offer) or the solution space. Thank you!

[ianterrell]

The topics from #108, #151, and #242 are related: how to support multiple CSS files, whether those are in engines/gems or elsewhere in the Rails application.
...
I'd love feedback from y'all on either the problem statement

I only want to chime in that in #108 I am not necessarily talking about building multiple CSS files per se, but rather allowing a single Tailwind generator to see all of an engine's views, partials, view components, and other files that contain Tailwind classes. When Tailwind generates its CSS file it scans all the files in the content configuration to know which utility classes it needs to include.

I know everyone working on this knows the above — I'm just including it for thoroughness since I didn't read this issue as exactly speaking to that.

the gem's rake tasks tailwindcss:build and tailwindcss:watch, as well as the Puma plugin and/or the engine server hook from #347, would be extended to build multiple Tailwind CSS files.

I may be misinterpreting this, but — I think what you're saying is that each engine would know about its own files with its own config file, and Tailwind would build a CSS file per engine which would be accessible. I don't know that it would necessarily matter, but I find it preferable to have a single Tailwind-generated CSS file. I think we're the odd ducks, but my work's main app is built with something like a Component-Based Rails Application approach, and we have ~30 engines. There would end up being a lot of duplication in each Tailwind file for our use case, and it would be cumbersome in the layouts to figure out which Tailwind CSS files to include in the header when we render view components from other components (via dependency injection).

Hopefully I haven't misinterpreted anything too much — thank you & all for the work on this gem & topic!

[flavorjones]

@ianterrell Thanks for clarifying your needs! Hearing that you've got 30+ engines and would want to render views from other engines is good information.

Maybe it would be better for engines to register their asset and view paths in an initializer, and then have just one tailwind css file? 🤔 I'm curious if this is how other folks feel, too!

[javierjulio]

@flavorjones hello and thank you. 👋🏻 As maintainer of ActiveAdmin, I'm interested in seeing this capability since with ActiveAdmin v4 beta it's now built with Tailwind but I wasn't able to use this gem successfully with an engine. Some of our users have managed to hack in tailwindcss-rails support. It would help to have the option to support multiple Tailwind config files so that way users with a large admin (or any large Rails engine) can have a separate Tailwind setup (e.g. different plugins) from their Rails app if desired.

[flavorjones]

@javierjulio Thank you for articulating your needs! The use case of a large admin is exactly what I had in mind when I made my original suggestion (multiple configs and multiple output CSS files. I really want to support this use case.

[dhh]

Would be happy to see engines supported, but imo the focus should be on expanding the files TW uses to look for classes in. Rather than trying to have multi outputs. I think in almost all cases, we're better off just producing one output for all classes found. And it'll be much easier, and we should be able to do so virtually without specific configuration.

[flavorjones]

OK, I'll spike on this approach.

[dhh]

Not saying we couldn't potentially also explore multiple outputs, but I'd want to see a clear case of where that makes a big difference before going down that path. And I think we get 90% of the value by simply allowing TW to produce the right output for all classes found in all dependencies.

[mattalat]

We have a case where we manage the general front-end (basic assets, configuration, layout partials, some components) in a gem containing a Rails engine. Our teams are small and make many small, separate applications, so extracting most of the front-end matter lets us develop quickly and keeps updates centralized and more manageable.

It would be nice for us to have a way to set up and import a standard tailwind config from the gem and merge it with customizations for each app. There is almost certainly a way to do this without building it into this gem, but I thought I'd mention it anyway.

The more desired feature would be to add our gem's views and components to the paths monitored by this gem.