🦋 Changeset detected

Latest commit: 1d452b3

The changes in this PR will be included in the next version bump.

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

@benmccann @jycouet

Hey guys, this is Chris from Skeleton. We're super excited about the Tailwind v4 update as well, but we're preparing to launch our next major release as soon as next week. As such, we have not had a chance to even touch Tailwind v4 yet to ensure Skeleton is compatible.

We're using sv as part of our onboarding for SvelteKit projects and we are aiming to default to the Tailwind (v3) install by default. So if it's not too much trouble, would it be possible to add a prompt and/or flag to ensure folks can set which version is installed? Currently we're recommending the following in our guide:

npx sv create --template minimal --types ts my-skeleton-app

I know this is very much an "us" problem, but Tailwind is the lifeblood of our project, so a flag to default to Tailwind v3 temporary would no doubt save us from a flood of support tickets!

Once we can confirm all is well with v4 then by all means, let's open that floodgate! I'm going to set some time aside to test this tomorrow. Really though, we're down to collaborate on whatever is required to make this happen. Just let me know. Thanks!

Could you just use a pinned version of sv like npx sv@0.6.16 create ...?

@benmccann as long as users would get the latest packages for Svelte/SvelteKit that would probably be fine for now.

What I'm worried about is we might get in there and realize we have to completely replace our entire Tailwind Plugin to resolve compatibility. That's the worst case scenario and would likely have a long lead time.

But I'll have a definitive answer on compatibility tomorrow. I'm going to run through and test our RC version with Tailwind 4 and see how it goes. Ideally it just works and this becomes much ado about nothing! fingers crossed

Pining sv sounds to be the right solution to me. Plus it's adding a motivation boost 😅💪

Pining sv sounds to be the right solution to me. Plus it's adding a motivation boost 😅💪

Ha, well this is the end of a 13 month dev cycle for our new update. It's been a massive undertaking. Not sure if I need motivation, a vacation, or a straight jacket at this point! 😄

But hey, we'll be one of the libraries of this scale with full Svelte 5 support! So there's that!

While svelte 5 was a big effort, I know that for libs it's also massive ! Congratz' 🚀🚀

@benmccann @jycouet

Hey guys - so a status update on this. A few of us have been testing Tailwind v4 + Skeleton v3 today. Unfortunately the news isn't what we wanted. Let me try to explain the situation as I currently understand it:

• In Tailwind v3 and prior they relied on a JS-based config file called tailwind.config
• This config file could be fed any number of plugins, that were generated also using JS
• These plugins could extend Tailwind with any number of utility classes (etc) provided in a CSS-in-JS format

So what we do for Skeleton is we use a mix of two approaches:

1. We use JS to generate a bunch of utility classes that follow a similar structure (all 77 colors from our themes, etc) and feed that directly into the plugin.
2. We also author some utility classes straight in .css files. For which we then have an in-house script that parses and converts those to CSS-in-JS format to feed those into our plugin

End users then install our plugin and have access to this vast number of extended classes and feature we provide. You can see most of that documented here.

However, Tailwind v4 takes another approach:

• There is no Tailwind config by default - config is handled primarily in CSS
• There are no more JS-based plugins - you just import CSS stylesheets to extend things
• They've even folded many of their first party plugins into the Tailwind core itself

The problem with this, is Tailwind v4 doesn't seem to be fully backwards compatible with our plugin. They do allow you to optionally provide a tailwind.config file, and you can definitely insert plugins (which we're doing), but the result is not great. Like 95% of classes we're trying are just not working. So far we've not found a common thread as to why.

So the plan is to continue to dig into this. See if perhaps there's some sort of bridge we can come up with. But otherwise the Skeleton core package (which is purely our Tailwind plugin) will need to have two separate versions:

1. A Tailwind v3 compatible version that works as described using the JS/plugin approach above
2. A Tailwind v4 compatible version that uses the direct CSS approach

While we have every intention on generating that latter option, it will likely have to be the focus of our next major release. This includes a tool to migrate user's theme file from CSS-in-JS format to pure CSS, etc. By my estimate it won't be a trivial change so my ETA is likely weeks, not days.

So again I raise the question above - what would be the repercussions of pinning sv for that length of time. What would users be missing out on? Would they be forced to use older versions of add-ons like Drizzle, Playwright, etc? That's my concern with that approach.

Thank you for all these details & info.

I have to say that I started this PR more like "Haaa cool, v4 is out, for new projects it could make sense to be on latest". I understand the issue with skeleton and every other UI lib based on tailwind.

In your doc, if you pin sv, yes you will get drizzle and co of this version too. But I don't know how often all these gets updated ? In the end it's maybe not a big deal ? For maybe few weeks ?

In the end, I let repo owners guide me in giving the direction.

Completely understand Jean, and I am terribly sorry if I have derailed any progress here. There's obviously plenty of folks that will want to use the latest and greatest version of Tailwind asap. I just wanted to make sure you guys were aware of the impact it could have on us.

Mostly this is just bad timing! We've been in crunch mode these last few weeks to polish off this big new update, so we completely missed the Tailwind v4 beta. That's 100% on me. But with a bit more time we'll get to the point we can fully support Tailwind v4. Which Im incredibly excited for. There's so many awesome features and many things will be much simpler for both us and end users.

I think we just need more hours in the day to get everything done! Heh

I'll say this - go ahead and merge whenever you guys are ready. Don't let us hold you back. We'll opt for pinning sv and then figure out what that means for our users in the meantime. It could be as simple as a message saying like:

Skeleton currently only supports Tailwind v3, so we pin `sv` to X version to ensure compatibility. This may mean some add-ons are are affected. Make sure to update those directly after setting up your new project.

@benmccann did you get the chance to see my updates ? Let me know if you have some other comment.

I filed an issue to ask them about plugins. Hopefully they'll be able to share some information. tailwindlabs/tailwindcss-typography#372

Open in Stackblitz

npm i https://pkg.pr.new/sveltejs/cli/sv@422

npm i https://pkg.pr.new/sveltejs/cli/svelte-migrate@422

commit: 1d452b3

Thank you everyone for all your work! This looks perfect, and CI is passing!

Apart from the discussion around @tailwindcss/typography and @tailwindcss/forms I don't see anything that's preventing us from merging this.

Let's give them a few days so that we can hopefully get a response on the status of those two plugins. If we don't get a meaningful response I think using tailwindcss@4 would outweigh the benefits of being able to add two plugins directly from the cli. Or am I missing something?

I think that you are not missing anything 👍

Just wanna say y'all are awesome. ❤️

Quick question: does it work with prettier-plugin-tailwindcss? prettier-plugin-tailwindcss docs.

When using Tailwind CSS v4 you must specify your CSS file entry point, which includes your theme, custom utilities, and other Tailwind configuration options. To do this, use the tailwindStylesheet option in your Prettier configuration.

{
  "tailwindStylesheet": "./src/app.css"
}

Based on the current state of plugins, and no official timeline provided, let's go with what we have here. As soon as the plugins are officially supported again, we will re-include them.

Thanks for all your work @jycouet and all the others for providing feedback!

As @sujyotraut mentioned, is there a reason why this is not added?

When using Tailwind CSS v4 you must specify your CSS file entry point

// .prettierrc
{
  "tailwindStylesheet": "./src/app.css"
}

┌  Welcome to the Svelte CLI! (v0.7.0)
│
◇  What would you like to add to your project? (use arrow keys / space bar)
│  prettier, tailwindcss

Must have missed that, #507