Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Appearance settings

Conversation

@kbond
Copy link
Contributor

@kbond kbond commented Feb 24, 2025

Closes #86
Closes #87
Fixes #84
Fixes #81

weaverryan
weaverryan previously approved these changes Feb 26, 2025
->beforeNormalization()
->ifString()
->then(static function (string $version): string {
return 'v'.ltrim($version, 'vV');
Copy link
Contributor

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

Copy link
Contributor

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

Copy link
Contributor Author

@kbond kbond Feb 26, 2025

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.x
  • tailwind: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.

Copy link
Contributor

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
bocharsky-bw previously approved these changes Feb 28, 2025
Copy link
Member

@bocharsky-bw bocharsky-bw left a 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

@davidnectarestudio
Copy link

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?

@kbond
Copy link
Contributor Author

kbond commented Mar 3, 2025

is there a planned release date about this feature

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
@kbond
Copy link
Contributor Author

kbond commented Mar 4, 2025

Regarding "Investigate the different binaries made available in v4+": The following existing OS/arch conditions have no equivalent in Tailwind v4:

  • Linux + armv7
  • Windows + arm64

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.

@kbond kbond merged commit 43100c1 into SymfonyCasts:main Mar 4, 2025
12 checks passed
@kbond kbond deleted the tw4 branch March 4, 2025 15:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Only download tailwind binaries if none are present Tailwindcss 4.0 support

4 participants

Morty Proxy This is a proxified and sanitized view of the page, visit original site.