Rails engine support · rails/tailwindcss-rails · Discussion #355 (original) (raw)

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!