npmライフサイクルを制する者は、リリース品質を制する：自動化の「深層」に潜る
多くのエンジニアが `npm install` や `npm run build` を日常的に叩いているが、npmが内包する「ライフサイクルスクリプト」の真の力を引き出せている者は驚くほど少ない。
我々テックリードの役割は、単にツールを動かすことではない。「人間に依存するチェック工程」をシステムの中に完全に埋め込み、ミスが起きる余地を物理的に排除することだ。今回は、パッケージ開発の信頼性を劇的に向上させる、npmライフサイクルの「裏口」を活用したハックを伝授する。
—
1. ライフサイクルを「配布前の防衛線」として活用する
npmには、`pre` および `post` という修飾子を付けることで、特定のコマンドの前後で自動発火するスクリプトが用意されている。特に重要なのは、配布物（パッケージ）の整合性を保証する以下の3つのフックだ。
ライフサイクル・トリガーの真実
- `prepack`: `npm pack` や `npm publish` の直前に実行。配布ファイル（dist）の生成と検証。
- `prepublishOnly`: `npm publish` の直前のみ実行。公開前の最後の大門。
- `postpack`: パッケージ作成後に実行。一時ファイルのクリーンアップや配布サイズの確認。
実践：`package.json` による自動バリデーション
以下の設定を `package.json` に組み込むことで、「未ビルドのまま公開」「型定義が壊れたまま公開」といったヒューマンエラーをCI以前のローカル段階で防ぐ。
{
“scripts”: {
// コンパイル＆型チェック。失敗すればpublishは中断される
“prepack”: “npm run build && npm run test:types”,
// 公開直前に、生成されたファイルサイズが異常でないか確認（CI用）
“postpack”: “node scripts/check-bundle-size.js”,
// 開発者への最終警告。意図しないタグ付けを防ぐための防壁
“prepublishOnly”: “node scripts/ensure-clean-branch.js”
}
}
なぜこれが必要か？
CIで`publish`する際、`prepack`をトリガーにすることで、ビルドプロセスを切り離すことができる。これにより「ビルド結果が壊れているのに公開された」という絶望的な事故を、配布プロセスそのものの構造によって封じ込めることが可能になる。
—
2. 「神プラグイン」と「設定の共有化」でチームの足並みを揃える
個人の生産性向上は重要だが、チーム全体の底上げには「強制力のある規律」が必要だ。
必須プラグイン：`husky` と `lint-staged`
ライフサイクルスクリプトは便利だが、npmのフックだけでは不十分だ。Gitのコミット時という「より早い段階」で検知するために、`husky` を導入し、以下の構成をチーム内で共有せよ。
.husky/pre-commit:
!/bin/sh
. “$(dirname “$0″)/_/husky.sh”
ステージングされたファイルのみを対象にlintを実行
npx lint-staged
package.json (lint-staged設定):
“lint-staged”: {
“.{js,ts,jsx,tsx}”: [
“eslint –fix”,
“prettier –write”
],
“.json”: [
“prettier –write”
]
}
これにより、「なぜかCIでlintが落ちる」という無駄なコンテキストスイッチが撲滅される。
—
3. 開発体験を極限まで高める「隠れたショートカットとTips」
毎日数回は打つコマンドの効率化は、年間で数時間の節約になる。
`npm alias` を超える `npx` の活用
`npm` 経由でローカルパッケージを実行する場合、いちいち `node_modules/.bin/` を探すのは時間の無駄だ。`npx` はそのためのものだが、以下のショートカットを習慣化せよ。
- `npx -c ‘…’`: 現在のパッケージの環境変数を読み込んだ状態で任意のコマンドを実行する。CIスクリプトのテストに最適。
- `npm run