-
Notifications
You must be signed in to change notification settings - Fork 31
Tailwind v4 Support #91
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
| ->beforeNormalization() | ||
| ->ifString() | ||
| ->then(static function (string $version): string { | ||
| return 'v'.ltrim($version, 'vV'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can I use something simple like v4? Like with Composer, I don't want to be bothered with exact versions
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is probably also important so we don't need to constantky update the recipe
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's important this be a "locked" version so all developers are using the same binary (there's a few issues about this).
If we allow composer-style versioning, we'd need a separate thing to "lock" it, which means an update command. I don't know we want to go down this road.
If anything, we could provide an update command that updates this value in config to the latest version:
tailwind:update: updates from say 3.4.1 to latest 3.xtailwind:update --major: updates from say 3.4.1 to true latest
You are right in that the recipe will always be locked to a specific version.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's important this be a "locked" version so all developers are using the same binary (there's a few issues about this).
You could opt into a lock by specifying the exact version, but everyone else could specify just 4 or 4.1
bocharsky-bw
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks solid to me
|
is there a planned release date about this feature? I'm working on a new project that customer requires TailwindCSS v4, can I do something to enable v4 meanwhile? |
I'm planning to finalize/release in the next day or so. |
- require `binary` or `binary_version` be configured - normalize `binary_version` (1.2.3 => v1.2.3) - determine version from binary - `tailwind:build` v4 compatible - `tailwind:init` v4 compatible - docs
|
Regarding "Investigate the different binaries made available in v4+": The following existing OS/arch conditions have no equivalent in Tailwind v4:
It's possible the other v4 binaries work for these conditions but I'm going to wait until it's reported so we can verify. |
binaryorbinary_versionbe configuredbinary_version(1.2.3 => v1.2.3)tailwind:buildv4 compatibletailwind:initv4 compatiblesymfonycasts/tailwind-bundlerecipe symfony/recipes#1383Closes #86
Closes #87
Fixes #84
Fixes #81