chore: move tailwindcss from dependencies to peer dependencies

[rtritto]

No description provided.

[philipp-spiess]

Hey! Appreciate the PR but we used a regular dependency for the fact that we need to ensure all Tailwind packages resolve to the same version. Are you running into any issues with this?

I'm going to close this PR for now but if you run into any issues with this setup please let us know.

[rtritto]

@philipp-spiess Using Tailwind as peer dependency, the installed version is respected.

Some example, having a package manager with the dedupe-dependencies-on-install option disabled.

1. On the first install, where the latest tailwindcss version is 4.0.0, the dependency tree will be:

   ├── [email protected]
   ├── @tailwindcss/[email protected]
   │   └── dependencies
   │   │    └── [email protected]

   Next, updating tailwind from v4.0.0 to v4.0.1, the dependency tree will be:

   ├── [email protected]
   ├── @tailwindcss/[email protected]
   │   └── dependencies
   │   │    └── [email protected]

   This is an issue where @tailwindcss/vite uses [email protected].

2. On the first install, where the latest tailwindcss version is 4.0.0, the dependency tree will be:

   ├── [email protected]
   ├── @tailwindcss/[email protected]
   │   └── peerDependencies
   │   │    └── tailwindcss@<SAME_INSTALLED_VERSION>

   Next, updating tailwind from v4.0.0 to v4.0.1, the dependency tree will be:

   ├── [email protected]
   ├── @tailwindcss/[email protected]
   │   └── peerDependencies
   │   │    └── tailwindcss@<SAME_INSTALLED_VERSION>

   It's right.

[philipp-spiess]

Thanks, but I still don't understand what the issue is with using a regular dependency? In your PR you pinned the peer dependency to a broad version range (^4) so it's possible to run the @tailwindcss/[email protected] with [email protected] which would break the build right now I'm afraid.

[rtritto]

I still don't understand what the issue is with using a regular dependency?

You should be able to install install:

• [email protected] with @tailwindcss/[email protected]
• [email protected] with @tailwindcss/[email protected]

In @tailwindcss/vite, that has tailwindcss as dependency, you can't control the main tailwindcss version.
In @tailwindcss/vite, that has tailwindcss as peer dependency, using the range or mimimum version, you can control the tailwindcss version (eg: use ^4 or ^4.0.1 or >4 or >4.0.1).
Using tailwindcss as peer dependency of @tailwindcss/vite, the tailwindcss dependency is installed once (as well the dedupe-dependencies-on-install option, in the package manager, is enabled or disabled).

In your PR you pinned the peer dependency to a broad version range (^4) so it's possible to run the @tailwindcss/[email protected] with [email protected] which would break the build right now I'm afraid.

With peer dependency ^4 you will accept every version >=4 and <5. It denotes which version of tailwindcss is supported by @tailwindcss/vite dependency.
@tailwindcss/[email protected] with [email protected] should not break @tailwindcss/[email protected]. If @tailwindcss/[email protected] breaks, means that peer dependency version of tailwindcss in @tailwindcss/[email protected] should be updated to ^4.0.1 (instead of ^4).

[philipp-spiess]

@rtritto I see. Just to clarify: We do not want you to use [email protected] with any version of @tailwindcss/vite other than the exact same one because we can't guarantee it will work. That's why we're pinning the version to a specific patch and why we don't use peer dependencies. You can still install tailwindcss in a different version in your project but once you add @tailwindcss/[email protected] it will need to use [email protected]. The idea here is to keep these versions in sync at all times, though!

[rtritto]

Ok, the release workflow should release all package at same time:

• release v4.0.0 for tailwindcss, @tailwindcss/vite, other pacakges
• release v4.0.1 for tailwindcss, @tailwindcss/vite, other pacakges
• etc

So, in the @tailwindcss/vite dependency, the version of tailwindcss peer dependency can be the same (locked) version of the workspace:

  {
    "name": "@tailwindcss/vite",
    "version": "4.0.0",
    "peerDependencies": {
      "tailwindcss": "workspace:*"
    }
  }

By this way, you need to update both tailwindcss and @tailwindcss/vite.
Eg:

• @tailwindcss/[email protected] requires [email protected] (peer dependency is [email protected]). The bundle of @tailwindcss/[email protected] will be:

    {
      "name": "@tailwindcss/vite",
      "version": "4.0.0",
      "peerDependencies": {
        "tailwindcss": "4.0.0"
      }
    }

• @tailwindcss/[email protected] requires [email protected] (peer dependency is [email protected]). The bundle of @tailwindcss/[email protected] will be:

    {
      "name": "@tailwindcss/vite",
      "version": "4.0.1",
      "peerDependencies": {
        "tailwindcss": "4.0.1"
      }
    }

• etc

[rtritto]

@philipp-spiess I did the changes in the commit rtritto@ee786ce

FYI @RobinMalfait