Input/Output paths are hardcoded

[danwetherald]

Why would it make sense to hardcode and not allow configuration options for the bin/rails tailwindcss:watch command?

We would like to generate a separate smaller tailwind css file that is for an embedded iframe for example, this should only include the css for a small subset of views for performance reasons.

Any plans to allow for the cli to allow for config params rather than them being hardcoded?

[flavorjones]

Hi @danwetherald, thanks for asking this question. It's nice to meet you.

Why would it make sense to hardcode

The contributors to this project have so far solved their problems without needing to introduce configurable paths. Hardcoded paths work fine in a vanilla Rails app.

If you have a different problem, that's great, let's talk about it. It's a weird flex to imply that the current implementation doesn't make sense because it doesn't meet your expectations.

We would like to generate a separate smaller tailwind css file that is for an embedded iframe for example, this should only include the css for a small subset of views for performance reasons

Rather than introduce configurable parameters for the commands, it may be more reasonable to use the Tailwindcss CLI directly on a custom tailwind.config.js file if you've got needs that aren't met by this gem. Have you explored that as an alternative option to this gem?

Like, if I'm being honest, there isn't much there there in this gem. It's basically:

1. generator templates for scaffolding and auth (which it sounds like you don't need),
2. a tailwind.config.js file (which it sounds like you want to heavily customize for your use case),
3. a wrapper for running the TailwindCSS CLI with some hardcoded paths,
4. and some glue for running those commands in a Procfile or in puma (which you can reproduce easily).

So I'm suggesting you just run the tailwind command you want with the config file that you need. The tailwindcss-ruby gem should make installation easy in case that's relevant.

Any plans to allow for the cli to allow for config params

This isn't a problem I personally have, so it's unlikely I'm going to do this work. And I'm not sure if the additional complexity is worth it without understanding your use case a bit more deeply. (The additional complexity comes from adding the first configuration option, of which this gem currently has zero.)

Also, if you haven't seen it already, there is a long-lived conversation going on at #355 which touches a bit on the config file and the subject of inputs and outputs. It's been hard to make a decision confidently while Tailwind v4 has been under development, but it sounds like a final release is due in the next few weeks, so I expect to pick that thread back up soon. It seems likely some configuration options will be introduced. Feel free to add your voice there if you wish.

[henrikbjorn]

@flavorjones I think that this use case might make sense to make it configurable activeadmin/activeadmin#8223

In our monolith we do something like this, since we have different Tailwind configs for our ActiveAdmin, our Marketing stuff, and our Account stuff. Which can be highly different.

So currently we are copy/pasting this ActiveAdmin rake task around for our different applications.

[flavorjones]

@henrikbjorn My question to you is the same that I asked above: if you're doing heavy customization already, why not use tailwindcss-ruby to install the CLI and just run the command with the specifialized configuration?

I'm trying to get a sense for whether tailwindcss-rails should even try to address the gem or engine use case.

[henrikbjorn]

@flavorjones Makes sense, it is easier to call the tailwind executables directly now with the new ruby gem.

My thought was to make it easier for the the compilation to hook into varius rake tests like asset precompilation and the test suite. But that wouldn't change just because the CLI here took additional arguments.

tldr; you are correct :)