Feel free to use my working blog (uses static shock with tailwind) for inspiration:
https://github.com/xdega/liamhockley_blog.github.io/

I always try to keep things as minimal as possible. But there are some customisations here. Alternatively, I would happily volunteer to create a more barebones tailwind project, based on my current setup.

Can we automatically include the Tailwind CLI tool?

@matthew-carroll Given my recent experience, it should be noted that the binary is platform dependent. As such, I think that automatically supplying it should be avoided (or done in such a way that binaries are platform-aware, when executed, and included for Mac, Windows, and Linux)

I went ahead and pumped out a template repo this evening, where I attempt to solve some of the problems mentioned above, and provide a sample TailwindCSS template with everything hooked up (cross-platform supported, pending verification/testing on windows/linux).

https://github.com/xdega/static_shock_tailwind

I adapted the index.html from the most "official" boilerplate I could find: https://github.com/tailwindlabs/tailwindcss-playground

Let me know what you think.

If this is something you would be interested in implementing, I can prepare a PR (or you can just snag it, whatever works)

One thing I'm wondering, with regard to to downloading the binary, is what the likelihood is that Tailwind will relocate those binaries. If they do, all Static Shock templates that use Tailwind would be broken...

One thing I'm wondering, with regard to to downloading the binary, is what the likelihood is that Tailwind will relocate those binaries. If they do, all Static Shock templates that use Tailwind would be broken...

Yeah. It probably makes sense to deliver a copy of the binaries. In my theme that I threw together, I baked binaries into the project (for each platform). Granted, Git is not the most ideal place to host such files.

That being said, there is probably a reasonable likelihood that the binaries will be rewritten at some point, in Rust.
At which point the binaries that are included should be updated.

Al alternative approach, could be like what Jaspr is doing, where they ask users to install the tailwindcss cli globally, and then the project accesses it with the assumption that it exists in the users PATH.

https://pub.dev/documentation/jaspr_tailwind/latest/

Note: That would require additional work for CI/CD pipelines as a tradeoff.

I think both options sound reasonable (per-project binary and global binary). Maybe supporting both makes sense? Can you think of any situations where someone might have a good reason to not want to globally activate Tailwind?

One possibility is Tailwind versioning. If they make a breaking change, and a developer has multiple projects, some of which are their own custom websites with Tailwind, then there could be an issue where activating a version for Website 1 breaks Website 2. I have no idea how likely that might be.

If we still want to provide binaries, we could add a static_shock_tailwind package to the mono-repo whose job is simply to aggregate Tailwind binaries, and then provide a root level file like tailwind_download.yaml, which then lists Tailwind versions and a URL to that binary within our own repo. In that case, resolution would be fully in our control.

I think both options sound reasonable (per-project binary and global binary). Maybe supporting both makes sense? Can you think of any situations where someone might have a good reason to not want to globally activate Tailwind?

One possibility is Tailwind versioning. If they make a breaking change, and a developer has multiple projects, some of which are their own custom websites with Tailwind, then there could be an issue where activating a version for Website 1 breaks Website 2. I have no idea how likely that might be.

If we still want to provide binaries, we could add a static_shock_tailwind package to the mono-repo whose job is simply to aggregate Tailwind binaries, and then provide a root level file like tailwind_download.yaml, which then lists Tailwind versions and a URL to that binary within our own repo. In that case, resolution would be fully in our control.

From my experience with Tailwind so far, they seem to be quite rigorous. As such I would think that breaking changes to their CLI would be relatively unlikely. This is also enhanced by the fact that TW has seen significant adoption, including with non-js projects that depend on their CLI binary being consistent.

I think the biggest reason someone might not want to install a global version of the CLI, would be the implications of having to spend CI/CD minutes on installing it for build runners. But there are always workarounds for that, and nothing to stop users from adding the binaries to their template (as I have done in my template).

The benefits of globally installed Tailwind, probably outweigh the negatives, IMHO.

If someone is working with multiple versions (I think somewhat unlikely), giving users the flexibility of BYOT (Bring Your Own Tailwind) allows them to use a binary, or any node package version (managed by their package manager of choice).

With that in mind, we could simply let the tailwind plugin be nothing more than an automatic "runner" for whatever tailwind version you have installed globally (or locally in your theme/project) by default, with the optional tailwindPath param being used to point to specific binaries as needed.