Support configuring version per profile#123
Merged
Merged
Conversation
josevalim
reviewed
Apr 25, 2025
josevalim
reviewed
Apr 25, 2025
josevalim
reviewed
Apr 25, 2025
josevalim
reviewed
Apr 25, 2025
josevalim
reviewed
Apr 25, 2025
josevalim
reviewed
Apr 25, 2025
josevalim
reviewed
Apr 25, 2025
josevalim
reviewed
Apr 25, 2025
josevalim
reviewed
Apr 25, 2025
Co-authored-by: José Valim <jose.valim@gmail.com>
Co-authored-by: José Valim <jose.valim@gmail.com>
The `--if-missing` argument causes this test to be flaky. Previously, when you had downloaded another version, the newer version would automatically be missing and thus always be installed. Currently, that's no longer the case, because you can have multiple simultanous tailwind installs, so in this case (after the first test run), the newer version already exists.
Contributor
Author
|
Is there anything that needs to be fixed/done from my side to get this merged? Would be nice if we could switch back from our fork to the upstream for our projects. |
SteffenDE
requested changes
May 21, 2026
I changed the implementation from raising to non-raising after the suggestion from José, but forgot to also update the docstring.
This now installs the given globally configured `version`, even if no profiles have been configured. This is not super useful because the `mix tailwind <profile>` command won't be usable, but maybe a valid use case when users only want to install the binary and call it themselves.
…even when `:path` is explicitly set
SteffenDE
approved these changes
Jun 3, 2026
| end | ||
|
|
||
| defp target_for_version(version) when is_binary(version) do | ||
| Application.get_env(:tailwind, :target, system_target(version)) |
Member
There was a problem hiding this comment.
Right now, if someone overrides the target, it is set for all profiles, which might cause issues if one profile is Tailwind 4 and another one Tailwind 3. So similar to the global path. But if someone runs into this a separate PR to move path and target into a per-profile config would be welcome, so it can be overridden if necessary, falling back to the global or default.
SteffenDE
reviewed
Jun 3, 2026
Member
|
🙌️ |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
In our project, we had a place where we were running multiple builds through multiple tailwind profiles, and one had already been updated to be compatible with v4 (and thus incompatible with v3), while the other is still stuck on v3 for now.
I added support to run a different version of the CLI for a profile. If no version is explicitly configured for the profile, it will fall back to the globally configured tailwind version.
This should be a backwards-compatible (aka non-breaking) change.