`@variant`のみ使用するCSSファイルがViteプラグインでスキップされるバグを修正

tailwindlabs/tailwindcss

@tailwindcss/viteのフィーチャー検出ビットマスクにFeatures.Variantsが欠落していたため、@variantのみを使用するCSSファイルが処理されずブラウザへ素通りしていました。1行の修正でこの検出漏れが解消されます。

背景

@tailwindcss/viteは、JSからインポートされたCSSファイルをTailwindが処理すべきかどうかを判定するフィーチャー検出の仕組みを持っています。ファイル内で使用されているディレクティブや機能をビットフラグとして検出し、Tailwind固有の機能が含まれていない場合はプレーンなCSSとして扱います。

今回の問題は、この検出チェックのビットマスクにFeatures.Variantsが含まれていなかったことで発生しました。@applytheme()、ユーティリティクラスを一切使わず@variantだけを使用するCSSファイルは、Tailwindの処理対象と見なされずにスキップされます。結果として@variantディレクティブがブラウザにそのまま送出され、未知のat-ruleとして無視されてしまいます。

#19964に掲載された再現例では、@import "tailwindcss"@custom-variant dark を持つメインのCSSと、@variant dark { ... } のみを含むoverrides.cssを組み合わせた構成が報告されています。overrides.cssはJS側から import './overrides.css' で読み込まれているにもかかわらず、@variant darkブロックが適用されない状態となります。

技術的な変更

packages/@tailwindcss-vite/src/index.ts内のRootクラスのフィーチャー検出ビットマスクにFeatures.Variantsを追加することで修正されています。

変更前:

if (
  !(
    this.compiler.features &
    (Features.AtApply | Features.JsPluginCompat | Features.ThemeFunction | Features.Utilities)
  )
) {
  return false
}

変更後:

if (
  !(
    this.compiler.features &
    (Features.AtApply |
      Features.JsPluginCompat |
      Features.ThemeFunction |
      Features.Utilities |
      Features.Variants)
  )
) {
  return false
}

このチェックは「いずれのフラグも立っていなければ処理をスキップする」というOR条件です。Features.Variantsを追加することで、@variantまたは@custom-variantのみを持つファイルもTailwindのコンパイルパスを通るようになります。既存の他フラグの動作には一切影響しません。

設計判断

既存のビットマスク構造を拡張する最小限の修正が採用されました。

フィーチャー検出の仕組み自体は変更されておらず、見落とされていたFeatures.Variantsフラグを列挙に加えるだけの1行相当の修正です。これは、バグ修正において「影響範囲を最小化しつつ正確に問題を解消する」という原則に沿った判断といえます。

まとめ

ビットマスクへのFeatures.Variantsの追加という小さな変更が、@variantのみを使うCSSファイルのサイレントスキップという実害のあるバグを修正します。フィーチャー検出に基づく処理パスの選択は効率的な設計ですが、新しいディレクティブを追加した際には検出条件の更新が必要となることを、本修正は改めて示しています。

記事メタデータ

Generated by:
Claude Sonnet 4.6 for DiffDaily
LLM Trace:
8a30f20a

この記事はAIによって自動生成されています。内容の正確性については、必ずソースコードやPRを確認してください。

品質レビュー結果

Review Status:
リトライ後承認
Review Count:
2回 (改善を経て承認)
Reviewed by:
Gemini 2.5 Pro for DiffDaily

Review Criteria:

記事構成 ✓ PASS

Title, Context, Technical Detailの存在と明確さ

リード文、背景、技術的な変更、設計判断、まとめという「総論→各論→結論」の構成が明確で、ガイドラインを遵守しています。

カスタムMarkdown構文 ✓ PASS

シンタックスハイライト・GitHubリンク記法の正確性

ファイル名付きシンタックスハイライト(```typescript:path/to/file.ts)とGitHubのIssue番号へのリンク([#19964](URL))が正しく使用されています。

対象読者への適合性 ✓ PASS

エンジニア向けの適切な技術レベルと表現

フィーチャー検出、ビットマスクといった専門用語を前提としており、専門知識を持つエンジニアという対象読者に適切です。

パラグラフ・ライティング ✓ PASS

トピックセンテンス・1段落1トピック・段落長

各セクション、各パラグラフが「総論→各論」の構造で書かれており、トピックセンテンスが先頭に配置されているため、非常に読みやすい構成です。

Diff内容との照合 ✓ PASS

コードブロックとDiff内容の一致

記事内のコードブロックは、提供されたDiffの内容を正確に反映しています。変更前後のコードの提示方法も分かりやすいです。

技術用語の正確性 ✓ PASS

技術用語の正確な使用

「フィーチャー検出」「ビットマスク」「at-rule」などの技術用語が、PRの文脈に沿って正確に使用されています。

説明の技術的正確性 ✓ PASS

技術的主張の正確性と論理性

「Features.Variantsがビットマスクに欠けていた」というバグの原因と、その修正による影響についての説明は、技術的に正確かつ論理的です。

事実の突合 ✓ PASS

PR情報による主張の裏付け(ハルシネーション検出)

記事内のすべての主張は、PRのDescriptionやDiffの内容によって裏付けられています。特に「設計判断」はDiffから読み取れる内容を適切に言語化したもので、ハルシネーションは見られません。

数値・固有名詞の確認 ✓ PASS

PR番号・コミットID・バージョン等の正確性

PR番号(#19966)、Issue番号(#19964)などの数値や固有名詞はすべて正確に記載されています。

タイトル・説明との一致 ✓ PASS

記事タイトル・説明とPR内容の一致

記事のタイトルは、PRのタイトル「fix(@tailwindcss/vite): include @variant in feature detection」がもたらす修正結果をユーザー視点で分かりやすく表現しており、内容と完全に一致しています。

外部知識の正確性 ✓ PASS

PRに記載のない外部知識(LTS、サポート状況など)の不使用

バージョン情報やリリース予定など、PR情報にない外部知識の追記はなく、提供された情報源に忠実です。

時間表現の正確性 ✓ PASS

時間表現がPR情報と一致しているか

「〜していました」といった過去形の表現が問題の状況を説明するために適切に使われており、時間表現の歪曲はありません。