Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Changes in Tailwind CSS v4

オープン
  • 何か問題がありますか？
#919 コメント 89 件 リアクション 3 件 担当者 0 名 GitHub で見る

関連するプルリクエストがすでにマージされています。

  • #991 @ineshbose による — マージ済み

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
20/100
issue の種類
機能追加
明瞭さ
説明が足りない
活発さ
停滞
技術スタック
nuxt, tailwindcss
領域
build-system, frontend

調査の方向性

Start with the Tailwind CSS v4 prerelease documentation and compare its configuration, source detection, and theme-variable changes with the module's current behavior. Review the discussion and existing features such as hooks and exposeConfig; done requires a decided migration direction and agreed scope for the next module version.

索引モデルが issue の本文から書いたものです。

説明

breaking-change enhancement help wanted question

Hi everyone,

I'm creating this issue to get an idea from the users of this module about certain changes and features in Tailwind CSS v4 that they'd like this module to integrate with.

If you haven't already, do give a read to the v4 prerelease documentation that covers all the changes:
https://tailwindcss.com/docs/v4-beta

I mention in #790 that this module mostly aims at installing and configuring Tailwind to your Nuxt project a breeze, and with this new version, Tailwind CSS has made it even easier; still, there are minor steps like configuring Vite within Nuxt (or webpack/other builders using PostCSS), setting up CSS, merging all the Nuxt layers, etc -- this is where the module would still be required.

There are a few more things that have changed in Tailwind CSS v4 that heavily influence on the approach for the next version of this module; I'm hoping to get comments on these functionalities (and more general bits I may have missed).

Configuration

Previously Tailwind required us to create a tailwind.config.js to enable minimum installation; this configuration file also helps in using plugins, safelists, and extending theme. This is no longer necessary, you can use v4 without a configuration file.

How would you configure the theme?

The idea of Tailwind v4 is that it will be more tailwind.css configuration focused, than tailwind.config.cjs (based on my understanding from this video). So, you have the @theme directive. Read more about this here - https://tailwindcss.com/docs/v4-beta#customizing-your-theme

With that said, any (existing) configuration files can still be used in v4 - https://tailwindcss.com/docs/v4-beta#using-legacy-configuration-files - but it will not be highly configurable through this approach (also note the usage of word "legacy").

Content Configuration

When creating a tailwind.config file, you were required to specify resolvable paths to your source code in the content property. This module also did that for you, so it wasn't necessary. However, projects have different natures of organising source code. Moreover, a file may exist in the tracker but not in the app lifecycle/tree; the class utilities from that file would still contribute to the final CSS.

Tailwind v4 now looks at the module graph and detects utilities accordingly. Still, paths can be configured explicitly; read https://tailwindcss.com/docs/v4-beta#configuring-source-detection.

Exposed CSS variables

There was a little section in Tailwind v3 docs about referencing (configuration) in JavaScript. Here again this module provided an exposeConfig feature 👼 that would provide tree-shakable, typed values to your configurations.

Tailwind v4 is based on CSS variables now, and the resolveConfig function is not exported anymore. https://tailwindcss.com/docs/v4-beta#referencing-theme-values-in-js

Given some of the changes pointed above, I'm trying to brainstorm on where we go next. It may be possible to maintain the current usage of the module to work with v4, but it may not enable its best potential. We can also change into a tailwind.css based module (have the module generate it and automatically integrate) which seems like a nice idea. We could just be a simple Vite/PostCSS plugin installer too 😄

So here's what I'm hoping to hear from you:

  1. are there current features from the module that you use and heavily rely on? (hooks, exposeConfig, etc)
  2. how much configuration do you tend to use for Tailwind, and if you'd move to using the new @theme, @plugin, etc. directives?
  3. is there anything in Tailwind v4 changes that you would want the module to bank on (like no longer providing our own content paths to use automatic detection, and also remove exposeConfig to use CSS variables), or possibly still have those abilities (that may not be as-usable at their best potential)?

Let me know what you all think. I'm excited to take this new exciting route that hopefully everyone can enjoy!

主要言語
TypeScript
スター
1.9k
フォーク
193
30日以内にマージされた PR はありません

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

nuxt-modules/tailwindcss のほかの issue

nuxt-modules/tailwindcss の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。