エンジニアの皆さん、こんにちは。開発環境の深淵へようこそ。
多くのフロントエンドエンジニアが、日々の業務で何気なく叩いている `npm publish`。しかし、その裏側で「どのスクリプトが、どのタイミングで、何のために実行されているか」を正確に理解している人は意外と少ないものです。
今回は、リリース事故を未然に防ぎ、CI/CDパイプラインを鉄壁にするための「npmライフサイクルスクリプト」の真実について、アーキテクトの視点から紐解いていきましょう。
—
1. なぜ「公開前フック」が重要なのか？
パッケージ開発において最も恐ろしいのは、「ビルド前のソースコードを公開してしまうこと」や、逆に「本来含めるべき成果物が欠落した状態でパッケージ化されること」です。
npmには、このプロセスを制御するための強力な「フック」が存在します。しかし、`prepare` や `prepublishOnly` といった似た名前のコマンドが混在しており、多くのエンジニアが「なんとなく」で設定してしまっています。ここを論理的に整理することで、あなたのリリースプロセスは劇的に安定します。
—
2. ライフサイクルスクリプトの「正しい順序」を知る
npmのライフサイクルには厳格な実行順序があります。まずは、主要な3つのコマンドの役割を「実務上の意図」で解釈しましょう。
1. `prepare`: 「配布可能な状態を作る」
- タイミング: `npm install` (引数なし)、`npm publish` の直前。
- 役割: 開発者が `git clone` して `npm install` した直後に、即座にビルド成果物が生成されるようにするためのもの。
2. `prepublishOnly`: 「公開のゲートキーパー」
- タイミング: `npm publish` の直前のみ。
- 役割: 「これを通らないと公開させない」という厳格なチェック（型チェック、テスト、ビルド検証）を行う場所。
3. `prepack`: 「パッケージ化の直前」
- タイミング: `npm pack` や `npm publish` の直前。
- 役割: ファイル構造を配布用に最適化するための最終調整。
比較表：どっちを使うべきか？
| 特徴 | `prepare` | `prepublishOnly` |
| :— | :— | :— |
| 実行環境 | ローカル・CI・公開時 | 公開時のみ |
| 主な用途 | ビルド成果物の生成 | リリース前のテスト・検証 |
| 推奨運用 | `dist` 生成などのビルド | テスト成功の保証 |
—
3. 実践：リリース事故をゼロにする最強設定
では、実際に `package.json` をどう構成すべきか、具体的な設定例を見てみましょう。
{
“name”: “my-awesome-package”,
“version”: “1.0.0”,
“scripts”: {
“build”: “tsc”,
“test”: “jest”,
“prepare”: “npm run build”,
“prepublishOnly”: “npm run test && echo ‘テストOK！公開を開始します'”
},
“files”: [
“dist/”,
“README.md”
]
}
この設定の意図（ここが重要！）
- `prepare` でビルドを自動化: 誰がどこで `npm install` しても、必ずビルドが走るため「ビルドし忘れて納品」という人為的ミスを排除します。
- `prepublishOnly` でテストを強制: `npm publish` を叩くと、まず `test` が走ります。テストが失敗すればコマンド自体が中断されるため、バグ混入パッケージが世に出ることは物理的に不可能になります。
—
4. プロの「.npmignore」戦略：filesフィールドとの併用
「不要なファイルがパッケージに含まれてしまう」問題の解決策は、`.npmignore` だけに頼らないことです。
ベストプラクティスは「ホワイトリスト方式」です。
`package.json` に `files` フィールドを記述すると、npmは「ここに書かれたもの以外は一切含めない」という挙動をとります。
{
“files”: [
“dist”, // ビルド済みのJSファイルのみを公開
“index.d.ts” // 型定義ファイル
]
}
この設定により、`src/` 内の生ソースコードや、ローカル開発用の `config` ファイル、`.env` などが誤って流出する事故を、設計レベルで防ぐことができます。
—
5. 最後に：なぜこの知識が「あなたの価値」を上げるのか
初心者はツールを「動かす」ことに必死ですが、アーキテクトは「ツールにガードレールを敷く」ことに集中します。
今回解説したライフサイクルを理解し、CI/CDやローカル環境で「事故が起きようのない仕組み」を構築できれば、あなたは「コードを書く人」から「開発プロセスを設計できるエンジニア」へと進化します。
毎日の作業が少しずつ自動化され、堅牢になっていく。その積み重ねこそが、開発効率を極限まで引き上げる唯一の道です。ぜひ今日、あなたのリポジトリの `package.json` を見直し、この「守りの設計」を組み込んでみてください。世界が少しだけ、安全で快適になるはずです。
それでは、素晴らしいビルドライフを！