ESM 用型定義を @tailwindcss/postcss に提供

tailwindlabs/tailwindcss

@tailwindcss/postcss が ESM インポーター向けに正しい型宣言ファイル(dist/index.d.mts)を配布できるよう、package.jsonexports マップを条件別に分割しました。これにより TypeScript 6.0 以降や Deno の型チェックで発生していた TS1192 エラーが解消されます。

背景

ESM コンテキストで export = 形式の型宣言が使用されていたことが、TypeScript 6.0 でのハードエラー(TS1192)を招いていました。@tailwindcss/postcss@4.1.16package.json では exports.import を宣言しているものの、dist/index.d.tsCJS スタイルの export = _default となっていたため、ESM インポーターがデフォルトエクスポートを取得できませんでした。この問題は Deno 2.8.3+(TypeScript 6.0)で import tailwindcss from "@tailwindcss/postcss" を実行すると顕在化しました。

このエラーは NodeNext 解決策を使用した tsc では再現しないものの、実際のユーザー環境での型安全性を損ねるため、修正が必要とされました。

技術的な変更

packages/@tailwindcss-postcss/package.jsonexports 定義を importrequire のそれぞれに対して types フィールドを分離しました。具体的には、従来の単一 "types": "./dist/index.d.ts" を削除し、以下のように条件別に記述します。

{
  "exports": {
    ".": {
      "import": {
        "types": "./dist/index.d.mts",
        "default": "./dist/index.mjs"
      },
      "require": {
        "types": "./dist/index.d.ts",
        "default": "./dist/index.js"
      }
    }
  }
}

import 条件では dist/index.d.mts(ESM 用型定義)を、require 条件では従来通りの dist/index.d.ts(CJS 用型定義)を指すようにしました。この変更により、ESM インポーターは自動的に .d.mts を取得し、CJS コンシューマは .d.ts を引き続き利用できます。

同様の構成は既に @tailwindcss/vite が採用しており、今回の修正はそのパターンを @tailwindcss/postcss に統一する形となります。

設計判断

PR では exportstypes フィールドを importrequire それぞれに分割する方針が採られました。これは新たに export default に置き換えるという代替案(index.d.ts の内容変更)と比較して、後方互換性 を最小限に抑える選択です。CJS 利用者は export = 形態の型定義をそのまま使用でき、既存のビルドやランタイム挙動に影響を与えません。

また、package.jsonexports マップはモジュール解決時に直接参照されるため、条件別に types を指定することで 型解決ロジックの単純化ファイル構造の明示化 が実現します。これにより、将来的に他のサブパッケージ(例: @tailwindcss/node)でも同様のパターンを容易に導入できる設計基盤が整います。

まとめ

本変更は ESM インポーターが正しい型宣言ファイルを取得できるよう exports マップを分割し、TypeScript 6.0 や Deno での型エラーを解消しました。CJS 互換性は保持したまま、型解決の一貫性を高める設計判断が行われ、他パッケージへの展開も容易です。

記事メタデータ

Generated by:
gpt-oss-120b for DiffDaily
LLM Trace:
e3f87e44

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

品質レビュー結果

Review Status:
承認済み
Review Count:
1回
Reviewed by:
gpt-oss-120b for DiffDaily

Review Criteria:

記事構成 ✓ PASS

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

リード文 → 背景 → 技術的な変更 → 設計判断 → まとめ の流れが明確で、各部の要素が揃っています。

カスタムMarkdown構文 ⚠ WARNING

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

コードブロックのファイル名付きハイライトは正しい形式です。ただし、PRリンクが "[PR #20228](...)" となっており、要求された "[#20228](...)" 形式と若干異なります。

対象読者への適合性 ✓ PASS

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

エンジニア向けの専門的な記述で、初心者向けの余計な説明はありません。

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

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

各セクションが総論・各論・結論のパラグラフ構成になっており、トピックセンテンスが先頭にあり、1段落は1トピックで、長さも適切です。

Diff内容との照合 ✓ PASS

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

記事中の JSON コードブロックは提供された Diff の変更内容と完全に一致しています。

技術用語の正確性 ✓ PASS

技術用語の正確な使用

用語(ESM、CJS、TS1192、exports、types など)は PR と一致し、誤用はありません。

説明の技術的正確性 ✓ PASS

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

技術的な説明は PR の記述と合致しており、因果関係も正しく示されています。

事実の突合 ✓ PASS

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

記事の主張はすべて PR の情報(タイトル、Description、Diff)で裏付けられており、推測や捏造はありません。

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

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

PR 番号 #20228 などの数値は正確です。

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

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

記事タイトルは PR タイトルの内容を適切に日本語化しており、意味合いにずれはありません。

外部知識の正確性 ✓ PASS

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

LTS やリリース日程等、PR に記載されていない外部情報は含まれていません。

時間表現の正確性 ✓ PASS

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

時間表現の歪曲はなく、PR の記述と一致しています。