Add support for custom tailwind css installs

[oliverandrich]

Given the existence of node-wheel-binaries on PyPI and the broken PyCharm plugin for Tailwind CSS, which relies on a locally installed Tailwind CSS, it might be an idea to another mode for the library.

The library currently supports three modes:

1. By default it uses the official CLI builds.
2. A locally installed binary can be used by setting TAILWIND_CLI_PATH to the complete path.
3. Install an externally built binary by specifying TAILWIND_CLI_SRC_REPO and TAILWIND_CLI_ASSET_NAME.

With the introduction of Tailwind CSS 4.x support, the library relies on checking the major version of Tailwind CSS. This is necessary because of the change behaviour concerning configuration but also because the --config parameter isn't available in Tailwind CSS CLI 4.x.

This breaks as mentioned in https://github.com/django-commons/django-tailwind-cli/issues/150#issuecomment-2646366386 the behavior for externally build versions of Tailwind CSS, that don't follow the official versioning scheme. This applies for example to https://github.com/dobicinaitis/tailwind-cli-extra if you try to install it using the settings TAILWIND_CLI_SRC_REPO and TAILWIND_CLI_ASSET_NAME.

Based on the things stated above, I am considering changing the behavior of the library and supporting the following modes:

1. By default, it uses the official CLI builds and can support Tailwind CSS 3.x and 4.x.
2. A globally installed binary can be used by setting TAILWIND_CLI_PATH to the absolute path.
3. Install an externally built binary by specifying TAILWIND_CLI_SRC_REPO and TAILWIND_CLI_ASSET_NAME.
4. A project local installed binary is used. This installation is based on node-wheel-binaries and fully encapsulated by the library. It would only introduce a package.json file to the project.

For mode 2, 3 and 4, a new variable TAILWIND_CLI_LEGACYis introduced. If it is set to True, the library assumes the interface of Tailwind CSS CLI 3.x and otherwise the interface of Tailwind CSS CLI 4.x. The default would be False.

The advantage of mode 4 is, that it adds support for PyCharm without any awful hacks, without the necessity to handle a node installation yourself. And it might also be the easiest way to add support for DaisyUI and friends.

Discuss! Feedback welcome.

[oliverandrich]

It might even be an idea to completely switch to a solution based on node-wheel-binaries? The only disadvantage is, that it needs more disk space compared to the prebuilt CLI. 90 MB for a shared binary vs. 160 MB per project.

Or just combine option 3 and 4 by dropping option 3, but extending option 4 by the possibility to install additional node packages like daisyUI.

[applewebbo]

+1 for latest solution with the possibility to install also plugin like daisyui. My current setup involves installing daisyui using bun. If I can get rid of that part it will be great

[adamghill]

Option 4 (or combining 3+4) makes sense to me. The extra disk space is a trade-off I'm personally ok with. 👍

[oliverandrich]

I made up my mind. The whole issue was started by my decision to support Tailwind CSS 3 and 4 in version 4 and upward. This was a bad decision. Kicking out Tailwind 3 support and directing people to version 2.21.1 of this library makes way more sense. The code gets easier again, and there will be no issue with tailwind-cli-extra and so on.

I think I will also cancel the approach based on node-wheel-binaries. I still not happy, to have node_modules and package.json in my project. On Bluesky, I got an interesting hint to https://npym.dev/back/simple/. Seems a nice way to install node packages in a vendored way in your project. But I have to evaluate it.

And I also have plans to get rid of the boilerplate configuration of Tailwind CSS. It should only be present if you like to override it.

[oliverandrich]

This issue has been resolved for an upcoming release.

https://github.com/django-commons/django-tailwind-cli/blob/main/CHANGELOG.md#420-unreleased