[#69] Tailwind 4 upgrade

[joshuapease]

Overview

• Upgrade to Tailwind 4 #69

Upgrades Tailwind to v4.

Really wasn't that bad, the npx @tailwindcss/upgrade@next command worked well.

Here are the manual changes I made (more details in code comments).

• When using only the .border class, TW uses currentColor instead of the default gray-200. I manually added border-gray-200 back to all instances of border that lacked a color class.
• I Ported the JS config to app.css fortunately we didn't have a lot of unique changes other than our custom sizes and using the selector mode for our dark theme.
• Migrated to Tailwind's max- media queries.
• I resolved some issues related to nesting dark:xyz variants within a ::after selector.
  • Additional details are provided in the comments.
• Resolved some issues with @keyframes in the dialog component.

JavaScript components / utilities.

Making components and utilities in JavaScript files seems to be "second class" to just writing them in CSS files. I couldn't even find details in the docs.

They still can be imported in the CSS-based Tailwind Config.

I'm curious if we should migrate these to CSS files since that seems to be the way TW is hidden. We do lose intellisense when we stop using the JS-based components. But I find that a very minor annoyance.

<button> tags use the default cursor

I noticed this minor change in TW 4's upgrade guide.

https://tailwindcss.com/docs/upgrade-guide#buttons-use-the-default-cursor

Buttons now use cursor: default instead of cursor: pointer to match the default browser behavior.

If you'd like to continue using cursor: pointer by default, add these base styles to your CSS:

@layer base {
  button:not(:disabled),
  [role="button"]:not(:disabled) {
    cursor: pointer;
  }
}

Our button components manually have cursors applied. But I'm curious if this a default we want to restore.

Other notes & unanswered questions

• PostCSS, Vite Plugin, etc

  • Postcss import is no longer needed
  • https://lightningcss.dev is used instead of postcss for vendor prefixing and modern syntax transforms, etc.
  • Is cssnano needed?
  • Would the Vite plugin still work with postcss-pxtorem

• Production build contains all color custom properties.

  • It might make sense to unset these by default and only add the colors your project needs.
  • There might be some chatter in the TW repo about stripping these out.
    • [v4] Tailwind generates a lot of unused styles tailwindlabs/tailwindcss#16571
    • Only expose used CSS variables tailwindlabs/tailwindcss#16211
      • Looks like it got reverted Revert: Only expose used CSS variables tailwindlabs/tailwindcss#16403
        

• Should we use dark as our "Reversed" style? What if we ever have a site that has a dark mode... but also needs a "reversed" section?

• resolveConfig went away. This is how we would import a JSON-ified version of TW into PHP. The Craft 5 starter doesn’t do this anymore, but it’ll need to be figured out for existing upgrades.

  • Show MW examples

• JavaScript plugins are considered “legacy”? How should we write things like button.js?

  • No suggestions for custom components after migrating to tailwind v4 tailwindlabs/tailwindcss-intellisense#1148
  • We lose intellisense by putting things in the @components layer. But I don’t know if that’s worth it.

• Starting Style is rad!

  • I experimented with upgrading the dialog animations to use that.
  • Code Demo

• Looks like ! for important moved to the end of the class in TW 4.

  • The TW4 upgrade guide makes no mention of important.
  • TW 3 Docs
    v3.tailwindcss.com/docs/configuration#important-modifier
  • TW 4 Docs
    tailwindcss.com/docs/styling-with-utility-classes#using-the-important-modifier

[joshuapease]

These keyframes weren't ending up in the final CSS and I was also getting some Typescript errors.

I don't think nesting keyframes within a class is technically valid. Seems like TW4 must be a bit more strict.

The issue was resolved by moving them outside of .dialog and making the opacity values strings.

[joshuapease]

Nesting dark:text-red-300 inside of the ::after selector was throwing the above error.

TW 4 docs recommend this setting to restore the TW 3 "selector" strategy for dark mode.

@custom-variant dark (&:where(.dark, .dark *));

However, I don't think TW3 used :where().

where() seems to confuse TW's compiler when it's nested inside of ::after

[joshuapease]

We could have opted for TW's vite plugin, but for now I kept things the way they were.

https://tailwindcss.com/docs/installation/using-vite

Wasn't sure if it would bypass all the other postcss features we use.

[joshuapease]

Looks like ! for important moved to the end of the class in TW 4.

The TW4 upgrade guide makes no mention of important.

TW 3 Docs
https://v3.tailwindcss.com/docs/configuration#important-modifier

TW 4 Docs
https://tailwindcss.com/docs/styling-with-utility-classes#using-the-important-modifier

[joshuapease]

TW-4 renamed a few utilities to make them more consistent. The automated migration handled most of them.

[joshuapease]

I had added some custom screens config to create max media queries.

But this is now part of TW 4 (or might have been since 3 actually)