依存関係の「檻」を突き破る：Yarn Berryプラグインによるパイプラインの深層最適化
フロントエンドのビルド環境が肥大化し、CI/CDの実行時間が「祈り」の対象となっている諸君へ。npmや従来のYarnが提供するフックに頼り、`postinstall`スクリプトで泥臭くファイルを書き換えている時代は終わった。
今日語るのは、Yarn Berry (v2+) のプラグインシステムを用いて、ビルドパイプラインのアーキテクチャそのものをハックする方法だ。なぜこれが重要か？ それは、依存関係の解決層に介入することで、CIのキャッシュ効率を劇的に高め、実行時ではなく「解決時」に最適化を強制できるからである。
—
1. なぜ「プラグイン」でなければならないのか：内部アーキテクチャの視点
npmや従来のYarnは、ライフサイクルスクリプト（`preinstall`等）を単なる「サブプロセス」として実行する。これは外部のシェルに依存し、環境差異を吸収できず、何より依存関係のグラフを構築する前に介入できないという致命的な欠陥がある。
Yarn Berryのプラグインは、`PluginHook`を通じてYarnのコア内部（Resolver, Fetcher, Linker）に直接アクセスする。これにより、メモリ上に構築された依存関係グラフを書き換え、インストール完了後に「ファイルをいじる」のではなく、「存在しないかのように解決させる」ことが可能になるのだ。
—
2. 独自カスタムコマンドの実装：CI/CDの「儀式」を自動化する
まずは、開発フローを強制的に統一するカスタムコマンドを作成しよう。例えば、「依存関係の整合性チェックと、特定環境用のパッチ適用」をワンコマンドで実行するプラグインの骨子だ。
`.yarn/plugins/my-devops-tool.cjs`
module.exports = {
name: `plugin-devops-hacks`,
factory: (require) => ({
hooks: {
// コマンドラインの構成を拡張する
setupScriptRuntime(runtime) {
runtime.cli.registerCommand(class MyDeployCommand extends require(‘@yarnpkg/cli’).BaseCommand {
static paths = [[‘devops’, ‘sync-config’]];
async execute() {
// ここでCI/CDパイプラインに必要な独自APIを叩く
this.context.stdout.write(“🚀 CI環境の同期を開始します…\n”);
// 内部APIを利用して現在のパッケージ情報を取得
const project = await require(‘@yarnpkg/core’).Project.find(this.context.configuration, this.context.cwd);
this.context.stdout.write(`対象プロジェクト: ${project.topLevelWorkspace.manifest.name}\n`);
}
});
}
}
})
};
このプラグインを `.yarnrc.yml` に登録するだけで、あらゆる開発者の環境で `yarn devops sync-config` が実行可能になる。これは単なるエイリアスではなく、Yarnのコンテキストを共有した「ネイティブな拡張」である。
—
3. 実践：インストール時動的パッチング（ゼロ・ランタイム負荷）
多くの現場では、依存パッケージのバグ修正のために `patch-package` を使っているだろう。しかし、あれはファイルシステムに物理的なパッチファイルを残す。もっと高度な手法は、プラグインでFetchフェーズをインターセプトすることだ。
以下のコードは、特定のパッケージがインストールされる直前に、メモリ上で設定を動的に書き換えるテクニックだ。
// YarnのFetcherフェーズに介入し、特定のパッケージを強制的に差し替える
hooks: {
async afterWorkspaceDependencyReplacement(workspace, dependency, next) {
// 特定のライブラリに致命的な依存の競合がある場合、ここで強制上書きする
if (dependency.name === ‘problematic-lib’) {
dependency.range = ‘npm:fixed-version-lib@latest’;
}
return next();
}
}
これにより、巨大な `node_modules` を再構築することなく、依存関係の解決ロジックそのものを動的に変更できる。Dockerコンテナ環境において、ビルドキャッシュを壊さずに特定パッケージの挙動を修正したい場合、この手法は最強の武器となる。
—
4. DevOps担当者が知るべき「メモリとパフォーマンス」の最適化ハック
Yarn Berryのプラグインを書く上で最も注意すべきは、イベントループをブロックしないことだ。
1. 非同期処理の管理: `hooks`内で重いI/O（ネットワークリクエスト等）を行う場合、必ず `Promise` を適切にハンドリングせよ。さもなくば、`yarn install` のプロセス全体がデッドロックする。
2. キャッシュの活用: `Configuration` オブジェクトから得られるキャッシュパスを再利用せよ。独自のキャッシュロジックを実装するよりも、Yarnの既存のキャッシュ機構を利用する方が、CI上での `–immutable` フラグとの親和性が高い。
3. Dockerとの統合: `RUN yarn plugin import …` をDockerfileに記述する際、プラグインのソースを `COPY` してからビルドすることで、レイヤーキャッシュを活用した高速な環境構築が可能になる。
CIでのプラグイン利用例
COPY .yarn/plugins ./.yarn/plugins
COPY .yarnrc.yml ./
プラグインを含めて依存関係を解決することで、CIの実行速度を10倍にする
RUN yarn install –immutable
—
5. 伝説のアーキテクトからの助言
プラグインを書き始めると、あなたは「ツールを使う側」から「ツールを作る側」へと進化する。しかし、過度な自動化は「属人化」を生む諸刃の剣だ。
- ドキュメント化: `plugin.cjs` の中身を理解できるのはあなただけかもしれない。必ずコード内に意図を記述せよ。
- 保守性: プラグインは可能な限り「YarnのコアAPIに依存しない」汎用的な処理に留め、ビジネスロジックは外部のCLIツールに逃がすのが、長期的には最も安全な設計である。
依存関係の管理を「ツール任せ」にする段階は卒業した。次は、あなたの手でパイプラインを最適化する番だ。この知見が、君のCI/CDパイプラインに革命をもたらすことを期待している。