これが実行可能かどうか、またはNode.jsリポジトリに属しているかどうかはわかりません。

何/なぜ

特定の依存関係では、（たとえば）全体的な環境で適切に機能するために特定のビルド構成が必要になる場合がよくあります。

この構成は、Babel構成、Webpack構成、またはそのパッケージ専用のカスタム構成である可能性があります。

現在のところ、パッケージを構成するための標準化された方法はありません。

パッケージにちなんで名付けられたpackage.jsonフィールドを配置する規則を使用する人もいますが、パッケージはそれを読み取ることができます。 しかし、それは十分に標準的ではありません。

いつ

パッケージが実行時またはビルド時にカスタム構成を必要とする場合。

どこ

どのように

JavaScriptが特定の場合にビルドステップを必要とする場合があります。 この構成機能には、任意のパッケージに渡すことができるオプションの「依存関係の構築」オプションがあります（ネイティブモジュールを構築する場合でも、JavaScriptを下位の形式にトランスパイルする場合でも）。

構成によっては、パッケージに特定の依存関係が必要になる場合がありますが、そうでない場合は必要ありません（feビルドの依存関係）。

したがって、パッケージシステムは、ユーザーが特定のパッケージ構成を持っている場合に、インストールする追加の依存関係を決定できるという点で、十分にスマートです。

たぶん、この機能は既存のネイティブモジュールシステムからJavaScriptシステム全体に拡張する必要があるだけです（使いやすい方法で、ネイティブモジュールはトリッキーです）。

これは、オプションの依存関係などにも非常に役立ちます。 configを使用すると、ライブラリが（たとえば） three代わりにbabylonjs three使用するように指定するのは簡単です。 これにより、適切な依存関係がインストールされます。 これはピアの依存関係に似ていますが、より簡単であり、オプションのdepsに依存する特定のパッケージには、特定の条件が指定されているかどうかを判断するために構成APIに確実にアクセスする標準的な方法があります（現在は注意が必要であり、node_modulesのシストムトラバーサルは非これらの場合の標準）。

現在の動作

• 該当なし

予想される行動

• 上で高レベルでカバー

別の例として、パッケージコンシューマーは、コードをさまざまな方法でコンパイルするために、通常のコンパイル済み出力ではなくパッケージソースを使用する必要がある場合があります（通常、私はWebpackでこれを実行したいと思っています）。

一般に、そのようなことには問題があり、これまでのところNPMは一般的な処理方法を提供していません。

誰

パッケージの作成者とそのユーザー

参考文献

• 該当なし