Pdf.js: pdfjs-distプロジェクトからwebpackpeerDependencyを削除します

丁度。 このような配布可能なパッケージにwebpackを"peerDependency"として含めることは明らかに間違っているため、削除する必要があります。

worker-loaderため、ピア依存関係が＃9249に追加されました。 リポジトリに置くのが間違っている理由について少し詳しく教えてください。 物事を壊さないことが確実なら、私はそれを取り除いても大丈夫です。

こんにちは、@ timvandermeij。 お返事をありがとうございます！

webpackはビルドツールであるため、通常は"devDependency"としてのみ意味があります。それ以外の場合は、ライブラリのビルドパイプラインに制限されます。 "peerDependency"として含めるということは、ユーザーがローカルにインストールするか（必要がない/気にしない場合でも）、 npm install毎回表示される警告を無視する必要があることを意味します。

私はworker-loaderに慣れていないので、ちょっとした塩でコメントしてください。 ただし、他のwebpackローダーと同様の場合は、通常、ビルド構成ステップとしてのみ必要であり、他には何も必要ありません。 また、ライブラリがWebの外部（ノードなど）で使用されることを意図しているコンテキストでは、ほとんど意味がありません。

pdf.jsは、ある種のwebpackプラグインとして機能する場合がありますか？ それが_is_の場合、依存関係としてローダーとwebpack両方を含めることは理にかなっているかもしれません。 しかし、それでも、その種のサポートは独自のリポジトリ/モジュールに抽出する必要があると私は主張します。

私は自由にレポをwebpack関連するすべてのものを取り出しました。 私のNodeアプリケーションでは、まだ完全に正常に機能しています。

依存関係としてwebpackを削除する計画はありますか？ @nfantone PRを提出する予定はありましたか？

@mishawakermanこの問題に対する「公式の」応答を実際に受け取ったことはありません。また、 webpackが依存関係としてリストされている理由がまだわかりません。 私の（限られた）直感によると、これは、 pdf.jsが、間接的にwebpack依存し、何らかの方法でリファクタリングする必要がある実装の一部に結合されている、より大きな問題の一部です。

この質問はIRCでも行われ、次の回答が得られました： https ：//mozilla.logbot.info/pdfjs/20180606#c14862530-c14862541。 要するに、私はWebpackのバンドル自体にはあまり詳しくありませんが、それが本当に例にすぎない場合は、削除できると思います。 ただし、PRを提出する前に、その場合を確認してください。

これを行うと＃9248が返されることを考えると、これを行うので閉じることは実際には良いオプションではありません。 代わりに、私たちがすべきことは＃9580です。これは、IRCのhttps://mozilla.logbot.info/pdfjs/20180606#c14862530-c14862634で説明されてい