一部のバンドラー・レンダラーライブラリは、内部で別言語のコンパイラのJS API（プログラム的なコンパイラホスト機能）を実行時に呼び出す設計になっていることがある。このライブラリ自身のpackage.jsonは、そのコンパイラを直接の依存として宣言していないことがある（利用側の環境に既にあるものを使う前提の設計）。

誤解しやすい条件

• 「そのツールチェーンは型チェック・ビルド時にしか要らない」という直感から、自作の公開npmパッケージでこの種のライブラリを使う際にツールチェーンをdevDependenciesに置いてしまうと、devDependenciesはパッケージ利用者のインストール時には入らないため、エンドユーザー環境で実行時にバンドラーがそのツールチェーンを解決できずエラーで壊れる。
• ローカル開発中はリポジトリ自身のdevDependenciesとしてツールチェーンがインストールされているため症状が出ず、パッケージ化（tarball生成）した上で別プロジェクトへインストールして初めて再現する。ローカルのテスト実行が通ることは、この種の依存漏れの検出にならない。
• 同様に、公開パッケージがプラグイン・シナリオ等の動的ロードに特定のトランスパイラのランタイムAPIを使う設計の場合、そのトランスパイラ自体もdependenciesに含める必要がある。

判断基準

• 依存先ライブラリが「実行時に別の言語ツールチェーンをプログラム的に呼び出す」設計かどうかを、そのライブラリのドキュメント・ソースで確認する（対象ツールチェーンパッケージの動的解決をしていないか）。該当する場合、そのツールチェーンを自パッケージのdependenciesへ昇格する。
• 対象ツールチェーンのメジャーバージョン互換性にも注意する。ネイティブ実装への移行など破壊的変更があるツールでは、意図しないメジャーバージョンが解決されるとJS API自体が失われ壊れることがあるため、バージョン範囲を固定気味にする。

検証

パッケージ化した成果物をリポジトリ外の新規ディレクトリへインストールし、そこから実際にCLI/ライブラリを実行して当該機能（バンドル・レンダリング等）が動くことを確認する。devDependenciesは新規インストールに含まれないため、これが依存漏れを検出する最も確実な方法になる。