推移的な開発依存関係の帰属を示す必要がありますか？
依存関係ライセンスを単一のファイルにバンドルするためのライブラリ/ CLIツールに取り組んでいます。現在、直接依存関係、推移的依存関係、直接開発依存関係のライセンスを収集しようとしています。
つまり、node_modulesにインストールされているパッケージのライセンスを収集しようとしています。推移的なdev-dependenciesは、dev-dependenciesの性質上、パッケージマネージャーによってインストールされません。
これらの推移的な依存関係のコード部分が、インストールされたパッケージに何らかの形で含まれるかどうかが心配です。
例：プロジェクト「A」はパッケージ「B」に依存しています。パッケージ「B」には、開発依存関係としてトランスパイラー「C」が含まれています。パッケージ「B」のトランスパイラー「C」によって生成されたコードには、単純なトランスパイラー結果だけでなく、トランスパイラー「C」からの古いブラウザーでは使用できない関数のポリフィルも含まれています。しかし、Transpiler "C"は推移的な開発依存関係であるため、プロジェクト "A"のnode_modulesにインストールされないため、手動でインストールしないと、Transpiler "C"のライセンスを適切に取得できません。できたとしても、Transpiler "C"の依存関係/ dev依存関係なども探す必要があります。
この架空のケースでは、推移的なdev-dependencyは1つしかありませんが、実際のシナリオでは、数百になる可能性があります。同じパッケージの複数のバージョンが、異なるパッケージの推移的なdev-dependencyとして定義されている可能性があります。ライセンス情報を収集するために推移的な開発依存関係を手動でインストールすることにより、これらの推移的な開発依存関係は独自の開発依存関係を持つことができ、これもインストールする必要があります。このプロセスは、すべての推移的な開発依存関係のすべての推移的な開発依存関係がインストールされるまで繰り返す必要があります。
質問は次のとおりです。推移的な開発依存関係に関するライセンス情報の収集に注意する必要がありますか？そして、もし私がそうするべきなら、どの時点まで？
私はすでに定期的な推移的な依存関係を気にかけていますが、推移的な開発依存関係が心配です。
回答
これは非常にトリッキーなシナリオです。そのため、自動化されたライセンスコンプライアンスツールはこれまでしか実行できません。あなたの分析は一般的に正しいようです。
実際には、BのライセンスはBの元のソースコードだけでなく、Bのトランスパイルコードもカバーしていると思います（少なくともBがトランスパイル形式で配布されている場合）。これにより、推移的な開発者の依存関係の問題を適切に回避できます。ただし、これはより一般的な問題を示しています。ライセンスメタデータが正確でない可能性があります。これは、自動化ツールがこれまでにしか機能しないもう1つの理由です。
汎用ツールを設計している場合は、パッケージメタデータに記載されているツールのメタデータをフェッチすることで、開発の依存関係と推移的な開発の依存関係の分析もトリガーするオプションを追加すると便利な場合があります（実際にインストールする必要はありません）。デフォルトでは、開発者の依存関係がライセンスステータスに直接影響することは期待していません（ただし、正しく説明しているように、特にポリフィルはこの期待に違反する可能性があります）。