Pdf.js: 从 pdfjs-dist 项目中删除 webpack peerDependency

确切地。 在这样的可分发包中将webpack作为"peerDependency"是完全错误的，应该删除。

由于worker-loader在 #9249 中添加了对等依赖项。 您能否详细说明为什么将它放在我们的存储库中是错误的？ 如果确定不会破坏东西，我可以将其删除。

嗨，@timvandermeij。 感谢您的回复！

webpack是一个构建工具，因此，它通常只作为"devDependency"有意义 - 或者仅限于库的构建管道。 将它包含为"peerDependency"意味着用户需要在本地安装它（即使他们可能不需要它/不关心它）或忽略每次在npm install上弹出的警告

我不熟悉worker-loader ，所以请保留我的评论。 但是如果它像任何其他webpack加载器一样，它们通常只需要作为构建配置步骤而不是其他任何东西。 此外，在库旨在在网络之外使用（如 Node）的上下文中，它没有什么意义。

在某些情况下， pdf.js充当各种webpack插件？ 如果它 _is_，它 _might_ 将加载器和webpack作为依赖项包含在内是有意义的。 但是，即便如此，我还是认为应该将这种支持提取到其自己的存储库/模块中。

我冒昧地将 repo 分叉并取出与webpack相关的所有内容。 在我的 Node 应用程序中，它对我来说仍然非常好。

是否有计划将 webpack 作为依赖项删除。 @nfantone你打算提交 PR 吗？

@mishawakerman我从来没有真正收到过对这个问题的“官方”回应——我仍然不知道为什么webpack被列为依赖项。 我的（有限的）直觉告诉我这是一个更大问题的一部分，其中pdf.js与其实现的某些部分耦合，该部分间接依赖于webpack并且需要以某种方式重构。

这个问题也在 IRC 上被问到，我们得到了这个答案： https: //mozilla.logbot.info/pdfjs/20180606#c14862530 -c14862541。 简而言之，我对 Webpack 捆绑本身并不是很熟悉，但如果真的只是为了示例，我想我们可以将其删除。 不过，请在提交 PR 之前检查是否是这种情况。

关闭，因为这样做并不是一个好的选择，因为如果我们这样做，#9248 将返回。 相反，我们应该做的是#9580，它在 IRC 中讨论过，网址为