Don't download a new binary if one is already present.

[sbrow]

As discussed in #84, if a user has not configured a binary version, but has already downloaded an outdated tailwind binary, the outdated version will be used instead of downloading a new version.

This prevents builds from breaking when users unexpectedly are upgraded from v3.x to v4.

I could add a message that warns users they are not using the most up-to-date version, if necessary.

[sadikoff]

Hey, nice work, can you please fix CS and tests

[sbrow]

Yep, sorry about that.

[bocharsky-bw]

I think we need to tweak the docs as well: https://symfony.com/bundles/TailwindBundle/current/index.html#using-a-different-binary-version

[bocharsky-bw]

Thanks for more changes, I still think we need to tweak the docs as well: https://symfony.com/bundles/TailwindBundle/current/index.html#using-a-different-binary-version

To make it clear about the process of finding the binary, WDYT?

[sbrow]

@bocharsky-bw My apologies. I did not realize that the docs were in the same repository as the plugin. I've done my best to explain the changes, but feel free to make edits as needed 😅

[bocharsky-bw]

Looks good to me, just a few minor comments

[bocharsky-bw]

Suggested change

	If instead you want to use only a specific version of tailwind, you can set the
	If instead, you want to use only a specific version of Tailwind, you can set the

[smnandre]

My 2 cents here: for the exact same problem, on the minify bundle i added a --force option to the install command.

DX feels easier to me (and can be added with little time).

Maybe another option?

[sbrow]

We certainly could add a force flag. If the team is amenable to that, I can add that to this PR.

[kbond]

I'm curious: is this still required after #83? Unless you manually set the version to null, you'll always get a specific version.

[sbrow]

@kbond Required? No. But slapping a band-aid on the problem doesn't solve the underlying issue. Automatically pinning the version just tips the scale in the other direction- instead of having an issue where certain users expect a specific version but get a new one, after #83 you'll now have users expecting to get the latest version, but they'll get an outdated one.

I opened this PR because the bundle didn't work as I expected. I presumed that when I ran tailwind:build for the first time, it would download the latest version of Tailwind, and continue using that version until either:

1. I Deleted ./var/tailwind
2. I Specifically asked for an upgrade of some kind.

This is in line with how composer works, if, like me, you commit the composer.lock file.

However, what was happening was that it was always updating to the latest version every time I ran tailwind:build, which the v4 release broke for me and other users.

---

I think this PR, combined with an additional PR (which I'm happy to author), that informs users that their version is out of date, and provides clear and easy instructions on how to upgrade, would be the best solution to this problem.

i.e. If a user hasn't set a pinned version, and their latest downloaded version is outdated, display a warning message during tailwind:build that says like

You are using tailwind v3.4.17, but the latest available version is v4.0.0.
Run php bin/console tailwind:update to use the latest version

[kbond]

This is in line with how composer works, if, like me, you commit the composer.lock file.

This is what #83 does. It's not perfect but aside from developing a composer-like versioning/update system, I think it's the best we have.

This PR doesn't address the issue of a new developer or a CI downloading an unexpected version (because the binary isn't available in these cases).

I'd be in favour of leaving the version config null (but required), then having this bundle's recipe adding the latest version.

additional PR (which I'm happy to author), that informs users that their version is out of date

I'm totally in favour of this but should look at your config, not the binary that's installed.

[sbrow]

The issue is that #83 sets the default version in the package itself, which means that as time goes on, that value will have to be updated as needed. When do we decide to set that number to v4.0.0? When is an appropriate time to upgrade? The answer will likely vary by company, by project, etc. Defaulting everyone to use the latest version that the tailwind-bundle that's confirmed to be compatible is different than defaulting to the latest version period.

This PR doesn't address the issue of a new developer or a CI downloading an unexpected version (because the binary isn't available in these cases).

This is by design. I was trying to preserve what I inferred was the intent of the plugin, so that existing users wouldn't be confused. If you want CI to work consistently, you need to pin every version of everything you can, that's why I love nix so much.

This PR is based on the assumption that there are two kinds of users:

1. Those that want to strictly control the version used.
2. Those that just want it to install something, and not have it suddenly break on them when they didn't ask it to update.

---

Frankly, I was just trying to help out so other users didn't fall in the same hole I did. If everyone is happy with #83, then feel free to close this PR.

[bocharsky-bw]

I'd be in favour of leaving the version config null (but required), then having this bundle's recipe adding the latest version.

This is an interesting idea IMO, though is it possible? If so, it would be simpler (more straightforward) than trying to guess the latest installed version. It will solve the problem for new users, everything will happen out of the box and they will have the latest supported version of Tailwind. For current users - well, it will be a BC break but should be easy to fix, you just need to specify a binary version explicitly in your config. With this strategy even if reverted that #83 - it would still work for all as you want, no automatic jump to a newer version when released. To upgrade to a newer version - just change the version in your config file.

You are using tailwind v3.4.17, but the latest available version is v4.0.0.

About this warning - I like it. We could check if there's a newer version available and if so - mention something like this in the output, but instead of saying run tailwind:update say something like "change the version in your config file". Not sure we even need a command for this that we will need to maintain.

Wdyt?