「postcss.config.jsってどう書けばいいの？」「Tailwindの設定をしても動かない…」そんな悩みを抱えていませんか？
PostCSSは、モダンなフロントエンド開発では欠かせないCSS処理ツールですが、設定ファイルの書き方やプラグインの組み合わせ方でつまずく人が非常に多いです。特に「公式ドキュメントを読んでも抽象的で理解しづらい」「環境ごとに書き方が違って混乱する」と感じている方も多いでしょう。
実際、PostCSSは「どのビルドツールを使っているか（Vite・Webpack・Next.jsなど）」によって設定方法が微妙に異なります。さらに、.js形式・.mjs形式の違いや、module.exportsとexport defaultの使い分けなど、初見ではわかりにくいポイントも多いのが現実です。
しかし、一度仕組みと正しい設定パターンを理解してしまえば、PostCSSは「開発効率を上げる強力な味方」に変わります。この記事では、難しく感じやすいPostCSSの設定を、初心者でも理解できるように実例ベースで丁寧に解説します。
この記事では、基本的な構成から実務レベルの応用設定まで順を追って紹介します。Tailwind CSSやAutoprefixer、cssnanoなどの代表的なプラグインを例に、動くサンプルコードを交えながら「なぜこの設定が必要なのか」までを解説。PostCSSを使った開発環境構築がスムーズに進むよう、つまずきやすいポイントにもフォーカスしています。
これからPostCSSを使い始める方も、既存プロジェクトで設定を見直したい方も、この1記事を読むだけで「PostCSS設定の全体像」と「実務で使える構成パターン」がしっかり身につきます。
「動く設定例がほしい」「環境依存で困りたくない」──そんなあなたにこそ、最後まで読んでいただきたい内容です。
PostCSSとは？postcss.config.jsの役割と基本構造
PostCSSは、現代のCSS開発において欠かせないツールです。ここでは、その基本的な概念と、設定ファイルであるpostcss.config.jsがプロジェクトで果たす役割を、初心者の方にも分かりやすく解説します。
postcss.config.jsとは？初心者でもわかる役割と基本構造
PostCSSは、よく「CSSのためのBabel」と表現されます。Babelが最新のJavaScript構文を互換性のあるJavaScriptに変換するように、PostCSSはプラグインを通してCSSを変換・最適化する強力なツールチェーンです。
Babelとは
Babel（バベル）は、新しいJavaScriptのコードを、古いブラウザや実行環境でも動くように変換（トランスパイル）するためのツールです。これにより、開発者は常に最新で書きやすいJavaScriptの機能を使って開発を進めることができ、一方でユーザーはどのブラウザを使っていても安定してアプリケーションを利用できるようになります。
では、PostCSSが何をすべきかを指示するのが、このpostcss.config.jsファイルです。
この設定ファイルは、PostCSSパイプライン全体を制御する司令塔の役割を果たします。具体的には、PostCSSに対して「どのプラグインを、どのような順番で、どのようなオプションで実行するか」を明確に定義します。
PostCSSの設定ファイルは、基本的にプラグインのリストをエクスポートするJavaScriptファイルです。
// postcss.config.js の基本構造
module.exports = {
plugins: [
// ここに実行したいプラグインを順番に記述します
require('autoprefixer'),
require('postcss-nested'),
// ...その他のプラグイン
]
}
postcss.config.jsの設置場所と読み込みルール
実際に試す前に、どこにファイルを置くべきかを知っておきましょう。
PostCSSの設定ファイルは、通常、プロジェクトルート（package.jsonと同じ階層）に配置することが強く推奨されています。
最新のモダンなビルドツール（Vite、Webpack、Next.js、Gatsbyなど）は、この場所にpostcss.config.jsまたはpostcss.config.mjsファイルが存在する場合、特別な設定なしにそれを自動で読み込み、PostCSSパイプラインを適用します。
ビルドツールが自動検出してくれるため、ほとんどの場合、Webpackのpostcss-loaderなどで設定を改めて記述する必要はありません。プロジェクトルートに配置するだけでOKです。
PostCSSがビルドに及ぼす影響と作用の仕組み
CSSコードがPostCSSによって処理されるプロセスを理解することは、プラグインの実行順序がなぜ重要なのかを把握するために不可欠です。
PostCSSは、以下の手順でCSSを処理します。
- パース（Parse）：
入力されたCSSコードを読み込み、PostCSSが理解できる構造（AST: 抽象構文木）に変換します。 - 実行（Run Plugins）：
postcss.config.jsに記述されたplugins配列の順番通りに、一つずつプラグインを実行します。各プラグインはこのASTを操作し、必要な変換処理（ベンダープレフィックスの追加、ネストの展開、圧縮など）を行います。 - ストリング化（Stringify）：
変換が完了したASTを、最終的なCSSコード（文字列）として出力します。
この作用順序において、プラグインの記述順は非常に重要です。例えば、「ネストの展開」を行うプラグインを「ベンダープレフィックスの追加」を行うAutoprefixerよりも前に実行しなければ、ネストされたセレクタに正しくプレフィックスが適用されません。
これが、PostCSSの設定、特にplugins配列の順番に細心の注意を払う必要がある理由です。
postcss.config.jsの基本構文と実例サンプル集
ここからはコピペ可能な具体的な設定ファイルの中身を見ていきましょう。
最小構成で動作するpostcss.config.jsの書き方
postcss.config.jsファイルは、基本的にNode.jsのモジュールとして、設定オブジェクトをエクスポートする形を取ります。このオブジェクトの中核となるのが、適用したいプラグインのリストを格納するplugins配列です。
以下は、Autoprefixerという最も基本的なプラグインを組み込んだ、最小構成で動作するpostcss.config.jsのコードブロックです。
/**
* PostCSS設定ファイル（最小構成のpostcss.config.js）
* コピペしてすぐに動作確認できます
*/
module.exports = {
plugins: [
// ベンダープレフィックスを自動で追加するプラグイン
require('autoprefixer')
]
}
コードの解説
module.exports = { ... }:
Node.jsのCommonJS形式で、このファイルの設定オブジェクト全体をエクスポートしています。plugins: [ ... ]:
PostCSSが実行するプラグインを上から順番に記述する配列です。この順番がパイプラインの実行順序となります。require('autoprefixer'):autoprefixerパッケージを読み込み、プラグインとしてPostCSSパイプラインに登録しています。
これこそが、実務で最も多く使われる基本形です。
module.exportsとexport defaultの違い｜CommonJSとESMの使い分け
JavaScriptの世界には、モジュールをエクスポートする方法として、大きく分けてCommonJSとES Modules (ESM)の2種類が存在します。これはpostcss.config.jsを作成する際にも関係してきます。
| 形式 | エクスポート構文 | ファイル拡張子 | 主な利用環境 |
|---|---|---|---|
| CommonJS | module.exports = { ... } | .js | Node.jsの標準、多くの古いビルドツール |
| ES Modules | export default { ... } | .mjs または .js (type: module時) | モダンブラウザ、Viteなどの新しいビルドツール |
多くのフロントエンド開発環境、特にWebpackや古いNode.js環境との互換性を考えると、上記で紹介したCommonJS形式（module.exports）を推奨します。この形式であれば、ほぼ全てのビルドツールで問題なく読み込まれるため、迷ったらこれを使うのがベストプラクティスです。
postcss.config.jsとpostcss.config.mjsの特徴と使い分け
PostCSSの設定ファイルには、.jsと.mjsという2種類の拡張子があります。
1.postcss.config.js (CommonJS)
- 特徴:
module.exports = { ... }構文を使用します。 - 使い分け: プロジェクトの
package.jsonで"type": "commonjs"（またはtypeの指定がない場合）のときに使用します。最も互換性が高い形式です。
2.postcss.config.mjs (ES Modules)
- 特徴:
export default { ... }構文を使用します。 - 使い分け: プロジェクトの
package.jsonで"type": "module"が設定されている場合、またはViteなどのESMベースのビルド環境を使用している場合に適しています。
もし、プロジェクトでES Modules（import/export構文）を全面的に使用しているのであれば、一貫性を持たせるためにpostcss.config.mjsを選択すると良いでしょう。
postcss.config.mjsの例
// postcss.config.mjs の例 (ES Modules形式)
// requireではなくimportを使います
import autoprefixer from 'autoprefixer';
export default {
plugins: [
autoprefixer() // requireと異なり、インポートした関数を実行
]
}
プロジェクトのセットアップに応じて、.jsか.mjsかを選択しましょう。どちらの形式でも、PostCSSの機能自体に違いはありません。
主要プラグイン別！実務で使える設定例
このセクションでは、実務で最も頻繁に利用される主要なPostCSSプラグインについて、具体的例を提供します。これらの設定例をコピー＆ペーストして、ご自身のプロジェクトに即座に適用してください。
ベンダープレフィックス自動化：Autoprefixerの最適設定とオプション
現代の開発において、手動で-webkit-や-moz-といったベンダープレフィックスを記述するのは非効率です。ここで活躍するのがAutoprefixerプラグインです。
ベンダープレフィックスとは
CSS（スタイルシート）の新しい機能や実験的な機能を、ウェブブラウザが先行して実装する際に、その機能名の前に追加する接頭辞（プレフィックス）のことです。近年では、多くの機能が標準化され、主要なブラウザがその標準に沿うようになったため、ベンダープレフィックスの必要性は減ってきています。しかし、アニメーションや一部の新しいレイアウト機能などでは、まだ使われることがあります。
1. Autoprefixerの導入と設定
Autoprefixerは、標準的なCSS構文で記述されたプロパティに対して、必要なプレフィックスを自動的に追加してくれます。
対象ブラウザの指定方法:
Autoprefixerがどのブラウザバージョンまでをサポートすべきかは、以下のいずれかの方法で指定します。
browserslistファイル:
プロジェクトルートに.browserslistrcファイルを置き、サポート範囲を定義するのが最も一般的です。package.json:package.jsonのbrowserslistフィールドに配列として記述します。
// package.json の例
{
// ...
"browserslist": [
"defaults",
"not IE 11",
"last 2 versions",
"> 1%"
]
}
2. 最適化されたAutoprefixerを含むpostcss.config.jsのコード例
Autoprefixerは通常、オプションなしで設定するだけで、上記のbrowserslistの設定を自動で読み込んでくれます。
// postcss.config.js - Autoprefixerの最適設定
module.exports = {
plugins: [
// requireでプラグインを読み込む
require('autoprefixer'),
// ※ Autoprefixerはbrowserslistを自動で読み込むため、
// ここでオプション設定を記述する必要はほとんどありません。
]
}
Tailwind CSSをPostCSSで動かすためのpostcss.config.js
ユーティリティファーストのCSSフレームワークであるTailwind CSSは、PostCSSを前提として動作します。Tailwind CSSを正しく機能させるには、特定のプラグインを決められた順番でロードすることが極めて重要です。
記述順序の鉄則
Tailwind CSSをPostCSSで利用する場合、以下の順番を守ってください。
tailwindcssautoprefixer
tailwindcssプラグインがまず、すべてのTailwindユーティリティクラスを生成し、その後にautoprefixerが、それらの生成されたCSSに対して必要なベンダープレフィックスを追加する必要があります。
Tailwind CSS用のpostcss.config.jsの具体的な設定コード
この設定は、Tailwind CSSプロジェクトでそのまま利用できる、最小限の設定例です。
// postcss.config.js - Tailwind CSSの必須設定
module.exports = {
plugins: [
// 1. Tailwind CSS本体のプラグイン。これがユーティリティクラスを生成する。
require('tailwindcss'),
// 2. Autoprefixer。Tailwindによって生成されたCSSにプレフィックスを追加。
require('autoprefixer'),
]
}
CSS圧縮・最適化に必須！cssnanoの導入例と条件分岐
開発環境では可読性の高いCSSが必要ですが、本番環境ではファイルサイズを最小限に抑えることが重要です。cssnanoプラグインは、CSSの圧縮（ミニファイ）と最適化を行います。
環境変数を使った条件分岐を用いることで、本番ビルド時のみcssnanoを実行するように制御できます。
// postcss.config.js - cssnanoの条件分岐設定
module.exports = {
plugins: [
require('autoprefixer'),
// ...その他の変換プラグイン
// 開発/本番環境を判定し、本番環境 (production) のみcssnanoを適用
// process.env.NODE_ENV が 'production' の場合にのみ実行
process.env.NODE_ENV === 'production'
? require('cssnano')({
// オプション: コメントやwhitespaceを全て削除
preset: 'default',
})
: false // productionでない場合は何もしない（falseを返す）
]
}
このコードでは、process.env.NODE_ENV（Node.jsの環境変数）を参照し、もし'production'であればcssnanoプラグインをオプション付きでロードし、そうでなければfalse（＝プラグインをスキップ）を返しています。
特定のファイルのみにcssnanoを適用する方法
PostCSSの設定ファイル内で、プラグインを関数として定義することで、処理対象のCSSファイル名（file.extname）に基づいて、プラグインを実行するかどうかを動的に判断できます。
これは、例えば「ベンダーライブラリのCSSは圧縮しないが、自前のmain.cssは圧縮したい」といった、より粒度の細かい制御をしたい場合に非常に有用なテクニックです。
postcss.config.js – 特定ファイル名による条件分岐の例
// postcss.config.js - ファイル名による条件分岐
module.exports = {
plugins: [
require('autoprefixer'),
// --- ここから特定のファイルのみに適用するTips ---
// プラグインの定義を関数でラップし、{ file } オブジェクトを受け取る
(context) => {
// PostCSSの実行コンテキストから、処理対象のファイルパスを取得
const fileName = context.file.basename;
// NODE_ENVが'production'であり、かつファイル名が 'main.css' である場合のみ
if (process.env.NODE_ENV === 'production' && fileName === 'main.css') {
console.log(`✅ [cssnano] Compressing: ${fileName}`);
return require('cssnano')({ preset: 'default' });
}
// 条件に合致しない場合は null (または false) を返してプラグインをスキップ
return null;
},
// --- Tips終了 ---
].filter(Boolean)
}
このコードでは、plugins配列の要素として関数を定義しています。PostCSSはこの関数を実行する際に、現在の処理に関する情報（contextオブジェクト）を渡します。
context.file.basenameを利用することで、現在処理中のCSSファイルのファイル名（例:main.css,vendor.css）を取得できます。- これにより、本番環境であっても、
main.cssというファイル名を持つCSSが処理されるときだけcssnanoが適用され、他のファイル（例:vendor.cssやライブラリのCSS）の処理がスキップされるようになります。
CSSネスト対応：postcss-nestedなど複数プラグインの正しい読み込み順序
SassやLessのようにCSSセレクタのネスト（入れ子）を可能にするpostcss-nestedのようなプラグインを使用する場合、複数のプラグインを扱う際の実行順序ルールを理解しておく必要があります。
実行順序ルールの原則:
- 構文変換/トランスパイル系プラグイン：
ネストの展開、変数・Mixinの処理など、CSS構文そのものを変更するプラグインを先に配置します。（例:postcss-nested,postcss-preset-env） - 最適化/後処理系プラグイン：
ベンダープレフィックスの追加、圧縮など、変換後のCSSに対して適用するプラグインを後に配置します。（例:autoprefixer,cssnano）
postcss-nestedを含むpostcss.config.jsの例
// postcss.config.js - 複数プラグインの正しい順序
module.exports = {
plugins: [
// 1. 構文変換系: ネストされたCSSを標準CSSに展開する
require('postcss-nested'),
// 2. 後処理系: 展開後の標準CSSに対してプレフィックスを追加する
require('autoprefixer'),
// (オプション) 本番環境でのみ圧縮
process.env.NODE_ENV === 'production' && require('cssnano'),
].filter(Boolean) // false値を配列から除去するためのテクニック
}
この配列内でpostcss-nestedがautoprefixerよりも先に実行されることで、ネストされたCSSが展開され、その展開後のコードに対してAutoprefixerが正しく作用します。filter(Boolean)は、条件分岐でfalseを返した場合にその要素を配列から除外する、便利なJavaScriptのテクニックです。
高度な設定とトラブルシューティング
PostCSSの設定に慣れてきたら、より柔軟な開発と安定した運用を実現するための高度な設定と、実務で遭遇しやすいトラブルシューティングの方法を知っておきましょう。
環境変数で実現する動的設定とベストプラクティス
postcss.config.jsは単なる設定ファイルではなく、JavaScriptファイルです。このJavaScriptの柔軟性を活かすことで、開発環境（Dev）と本番環境（Prod）で設定を動的に切り替えることができます。
最も一般的な動的設定は、Source Map（ソースマップ）の有効/無効の切り替えや、cssnanoのような最適化プラグインの有効化です。
以下の例では、環境変数process.env.NODE_ENVを使って、開発環境でのみSource Mapを有効にし、cssnano（CSS圧縮）を本番環境でのみ実行しています。
// postcss.config.js - 環境変数を使った動的設定
const isProduction = process.env.NODE_ENV === 'production';
const isDevelopment = process.env.NODE_ENV === 'development';
module.exports = {
// PostCSSの共通オプションを定義
map: isDevelopment ? {
// 開発環境ではインラインSource Mapを有効にしてデバッグを容易にする
inline: true,
} : false,
plugins: [
require('autoprefixer'),
// 開発と本番で共通の変換プラグイン
require('postcss-nested'),
// 本番環境でのみ、CSS圧縮・最適化を行う
isProduction && require('cssnano')({
preset: 'default',
}),
].filter(Boolean) // false (無効なプラグイン) を配列から除外
}
このアプローチは、ビルドツールが自動的に環境変数を設定する（例: ViteやWebpackのデフォルト設定）場合に特に強力です。これにより、開発時のビルド速度を維持しつつ、本番時に最適なCSSを生成できます。
設定が反映されない時の原因究明と解決策
「postcss.config.jsを編集したのに、なぜかCSSが変わらない！」これは誰もが一度は経験するトラブルです。原因究明と解決策をチェックリスト形式で確認しましょう。
1. プラグインのインストール忘れ
最も単純ですが、最もよくあるミスです。
確認点:
package.jsonのdependenciesまたはdevDependenciesに、使用したいプラグイン（例:tailwindcss、postcss-nested）が記載され、npm installまたはyarn installが実行されているか？
解決策:
npm install -D <プラグイン名>を実行し、依存関係を確実にインストールしてください。
2. ビルドツールの設定ミスまたはバージョン依存
ビルドツール（Webpack, Vite, Next.jsなど）がPostCSSの設定ファイルを正しく認識していない場合があります。
確認点:
- プロジェクトルート（
package.jsonと同じ階層）にpostcss.config.jsが置かれているか？ - Webpackを使用している場合、
postcss-loaderのバージョンや設定に問題がないか？（多くの場合、最新の環境ではpostcss-loaderの設定は不要です） - Vite PostCSS: Viteはデフォルトで
postcss.config.jsをサポートしますが、稀に設定が必要な場合があります。
解決策:
- ビルドツールの公式ドキュメントでPostCSSの読み込み方法を再確認してください。
3. ファイル名のスペルミス
PostCSSは特定のファイル名しか自動で読み込みません。
確認点:
- ファイル名が正確に
postcss.config.js、postcss.config.cjs、postcss.config.mjsのいずれかになっているか？（例:postCss.config.jsのように大文字が混ざっていないか）
4. キャッシュの残存
ビルドツールやPostCSS自体が、以前の処理結果をキャッシュしていることがあります。
解決策:
- ビルドツールを再起動する。
npm run cleanなどでビルドキャッシュを削除してから、再度ビルドを実行する。- 特にTailwind CSS PostCSS環境では、
node_modules/.cacheやビルドツールのキャッシュを削除すると解決することが多いです。
チーム共有に最適な保守性の高い設定ファイルの作り方
プロジェクトが大きくなり、チームでpostcss.config.jsを共有する場合、保守性が重要になります。設定ファイルをシンプルで読みやすく保つための設計原則を学びましょう。
1. 設定の外部ファイル化（条件分岐を隠す）
プラグインが複雑なオプションや環境変数による条件分岐を持つ場合、それらをpostcss.config.jsから切り出すとメインファイルが読みやすくなります。
// postcss.config.js の代わりに
const autoprefixerConfig = require('./config/postcss-autoprefixer.js');
const tailwindConfig = require('./config/postcss-tailwind.js');
module.exports = {
plugins: [
tailwindConfig, // Tailwind設定オブジェクト（配列でも可）
autoprefixerConfig, // Autoprefixer設定オブジェクト
// ...
]
}
2. プラグインを配列内の関数として定義する
プラグインをオプション付きでロードする際に、[require('plugin'), { option: value }]の形式を使うと、より構造的に設定を記述でき、可読性が向上します。
// postcss.config.js - オプション付きプラグインの記述方法
module.exports = {
plugins: [
require('tailwindcss'),
// 配列の第一要素にプラグイン、第二要素にオプションオブジェクト
['autoprefixer', {
overrideBrowserslist: ['> 0.5%', 'last 2 versions'],
}],
// ...
]
}
この配列形式は、PostCSSの多くのローダーやツールでサポートされている標準的な書き方であり、設定の意図を明確にするのに役立ちます。
よくある質問（FAQ） ❓
ここでは、PostCSSの設定、特にビルドツールとの連携に関する、フロントエンドエンジニアの皆さんが抱きやすい疑問（postcss config js example関連）に回答します。
-
Viteを使っているのに
postcss.config.jsが必要ですか？ -
はい、基本的には必要です。
モダンなビルドツールであるViteは、非常に高速で設定レスですが、PostCSSに関してはデフォルトで自動的にプロジェクトルートにある
postcss.config.jsを読み込みます。Vite自体は、PostCSSを依存関係として組み込んでいますが、実際にどのプラグイン（例：
tailwindcss、autoprefixer）を使うかをViteに教えるためには、postcss.config.jsファイルが必須となります。このファイルがないと、PostCSSは最小限の機能しか提供しません。Viteの特殊なケース: 非常にシンプルなプロジェクトで、PostCSSプラグインとしてAutoprefixerのみを使用したい場合は、package.jsonのbrowserslistを設定しておけば、Viteが裏で自動的にAutoprefixerを適用してくれることがあります。しかし、Tailwind CSS PostCSSのように複数のプラグインを使う場合は、必ずpostcss.config.jsを作成してください。
-
Webpackで
postcss-loaderは必須ですか？ -
いいえ、必須ではありませんが、場合によっては必要です。
PostCSSをWebpackパイプラインに組み込むためには、以前は必ず
postcss-loaderが必要でした。しかし、SassやLessの処理と同様に、最近のwebpack-cliや各種フレームワーク（Next.jsなど）のバージョンによっては、postcss-loaderを明示的に設定ファイルに記述しなくても、PostCSSの設定ファイル（postcss.config.js）を自動で検出し、CSSを処理してくれることがあります。- 推奨されるパターン:
postcss.config.jsを作成し、postcss-loaderの設定を最小限（または省略）にして、WebpackがPostCSS設定を自動で処理するのに任せるのが、モダンなベストプラクティスです。 - 必要なパターン:
古いWebpackのセットアップや、非常に特殊なローダーの順番制御を行いたい場合にのみ、module.rules内でpostcss-loaderの設定を明示的に記述する必要があります。
- 推奨されるパターン:
Q3. postcss.config.jsがない場合、PostCSSはどうなりますか？
✅ A. ほとんどの場合、PostCSSは機能しません。
postcss.config.js（または.mjs）は、PostCSSというエンジンに対して、何をすべきかを指示する設計図です。この設定ファイルがない場合、ビルドツールがPostCSSを起動しても、実行すべきプラグイン（plugins配列）が空であるため、CSSに対する変換処理はほとんど行われません。
- 例外: 前述の通り、Viteなどの一部のビルドツールは、
Autoprefixerなどごく一部の基本機能に限り、設定ファイルなしで動作させることがあります。 - 結論:
Autoprefixer 設定やTailwind CSS PostCSSのように、カスタマイズされた機能や複数のプラグインを利用する開発を行う場合は、必ずこの設定ファイルが必要です。
-
postcss.config.mjsを使うべきプロジェクトの基準は何ですか？ -
プロジェクトのモジュール形式が一貫してES Modules（ESM）である場合です。
postcss.config.mjsは、ES Modules（export default構文）を使用するために存在するファイル拡張子です。以下の条件のいずれかに当てはまる場合は、
.mjsを使うことを検討してください。package.jsonで"type": "module"が設定されている：プロジェクト全体がESM形式で統一されている。- ViteなどESMを標準とするビルドツールを使用しており、設定ファイル内でも
import/export構文を使いたい。
それ以外（特にWebpackや古いNode.js環境）の場合は、互換性の高い
postcss.config.js(CommonJS)を使用するのが安全です。
まとめ
ここまでPostCSSの基本から、Tailwind CSS連携、環境ごとの動的設定、さらにはトラブルシューティングまで、フロントエンドエンジニアが必要とする知識を網羅的に解説してきました。
この包括的なガイドをブックマークし、PostCSSの設定で迷ったときはいつでも参照してください。あなたのビルドパイプラインが、この記事の設定を通じて、より効率的で、より最適化されたものになることを願っています。
次のステップとして、ぜひこの記事を参考に、あなたのプロジェクトにまだ導入されていないcssnanoなどの最適化プラグインを試してみてください。CSSのファイルサイズ削減効果に驚くはずです！
PostCSSをマスターし、より良いCSSを生成する一歩を踏み出しましょう！
あわせて読みたい
