ツリーシェイキングの深淵：`sideEffects` フラグによるバンドル最適化の極致
フロントエンド開発において、バンドルサイズは単なる「データ量」ではない。それは、ブラウザのメインスレッドが解釈し、実行し、メモリ上に展開する「計算資源のコスト」そのものだ。
WebpackやRollupのようなモジュールバンドラーは、賢いツールだが「万能ではない」。彼らが最も恐れるのは、「このコードを消して、アプリが壊れないか？」という不確実性だ。この不確実性を排除し、ツリーシェイキング（不要コードの除去）を極限まで駆動させるための最終兵器が、`package.json` における `sideEffects` フラグである。
1. バンドラーを「沈黙」させるロジックの解明
なぜバンドラーは、明らかな未使用コードを削除できないのか。それは、多くのJSライブラリが「副作用」を内包しているからだ。
- グローバル変数の拡張: `Array.prototype.map` を書き換えるようなポリフィル。
- CSSのインポート: `import ‘./styles.css’`。これはJSとしては何もしないが、ビルド時には不可欠な副作用。
- DOMの直接操作: モジュール読み込み時にDOMを生成するロジック。
バンドラーは「副作用があるかもしれない」と判断したモジュールは、たとえエクスポートが一切使われていなくても削除できない。`sideEffects: false` を設定することは、「このパッケージは純粋な関数（Pure Functions）の集合であり、モジュールを読み込むだけで何らかの実行結果が変わることはない」と開発者が保証する宣言である。
2. sideEffectsの最適化戦略：段階的な「純化」
単に `false` を設定するだけでは、CSSや一部の特殊なライブラリが破壊される。以下の戦略で段階的に適用せよ。
ステップA：全域適用（Pureなライブラリのみ）
ユーティリティ関数集など、純粋なライブラリには即座に適用する。
{
“name”: “my-util-lib”,
“sideEffects”: false // 宣言：このパッケージ内のいかなるモジュールも副作用を持たない
}
ステップB：パス指定による「副作用の隔離」
CSSや特定の初期化ロジックを持つファイルだけをホワイトリスト化する。
{
“name”: “my-ui-library”,
“sideEffects”: [
“/.css”, // スタイルシートは副作用として保持
“/.scss”, // SCSSも同様
“./src/setup-icons.js” // アイコンの自動登録など、副作用が必要なファイルのみ明示
]
}
3. CI/CDパイプラインへの統合：破壊的変更の検知
`sideEffects` の設定ミスは、静的解析では検知困難な「ランタイムエラー」を引き起こす。これをCIでガードするために、「バンドルサイズ・プロファイリング」をパイプラインに組み込む。
GitHub Actionsでの自動検証パイプライン
`bundlesize` や `size-limit` を用いて、特定モジュールの削除が期待通りの削減量をもたらしているか追跡する。
.github/workflows/perf-check.yml
jobs:
check-bundle:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- run: npm ci
- run: npm run build
# size-limitを用いて、sideEffects最適化後のサイズ閾値を監視
- run: npx size-limit
4. 現場で震えるほど役立つ「内部ハック」
Webpack `sideEffects` の強制オーバーライド
依存先ライブラリが適切に `sideEffects` を設定していない場合、Webpackの `resolve.alias` や `module.rules` でそのパッケージだけを「強制的に副作用なし」として扱うハックが存在する。
// webpack.config.js
module.exports = {
module: {
rules: [
{
// 外部ライブラリのバグを修正するための強力なハック
test: /problematic-lib\/.\.js$/,
sideEffects: false
}
]
}
};
pnpmを用いた依存関係の可視化
`pnpm` を使用しているなら、依存グラフを可視化し、副作用が疑わしい巨大なパッケージを特定せよ。
依存ツリーを生成し、巨大なライブラリを特定
pnpm list –recursive –json > deps.json
内部的なモジュール解決を調査し、sideEffectsが効いていない箇所のボトルネックを特定
node_modules配下のpackage.jsonを再帰的にチェックするスクリプトを走らせるのが定石
5. アーキテクトからの提言：計測なき最適化は単なる浪費
`sideEffects` の最適化は、必ず「Webpack Bundle Analyzer」等による視覚化とセットで行うこと。
1. ビルド分析: `webpack-bundle-analyzer` で、削除されるべきコードがバンドル内に残っていないか確認する。
2. 差異計測: `sideEffects` 設定前後で、`main.js` や `chunk-vendors.js` のバイトサイズをCI上で出力する。
3. ベンチマーク: Lighthouseの `Total Blocking Time (TBT)` を計測する。JSのパースとコンパイル時間は、バンドルサイズの平方根に比例して増加するため、数KBの削減でも低スペック端末では劇的なUX向上を生む。
このフラグは、ただのメタデータではない。「あなたのコードが、ブラウザという限られたリソースの上でどう振る舞うべきか」を宣言する、エンジニアの意志そのものだ。
もしあなたが真のDevOpsを志すなら、まずは今すぐ `node_modules` の中を覗き、頻繁に使うライブラリの `package.json` がこの設定を怠っていないか確認してほしい。そこには、数メガバイト単位の「無駄な実行コスト」が眠っているはずだ。