有很多webpack软件包可以在捆绑中找到重复的软件包，其中最受欢迎的是重复软件包检查器webpack-plugin ，但它需要重新组装项目，并且由于有一项任务可以自动选择最佳版本的软件包，因此它找到了自己的替代解决方案。
好吧，或者我的故事是事实证明，如何在几秒钟内将捆绑包减少15％。
就像在许多拥有庞大代码库的大型公司中一样，存在很多通用逻辑，因此我们使用了发布在npm存储库中的通用组件。 它们分别通过lerna发布，在每次安装或更新公共组件之前，都会出现要安装哪个版本的问题。 lerna会覆盖使用已发布组件的所有组件（如果该版本以前是最新的）。 相应地，由于不与依赖项竞争，因此总会有一些组件彼此更好地兼容。
从开源项目中， nivo就是这样， 它们是lerna config 。
那么如何出现重复的依赖关系？ 以及如何消除它们？
假设您有一个带有以下package.json的简单项目：
{ "name": "demo-project", "version": "1.0.0", "dependencies": { "@nivo/bar": "0.54.0", "@nivo/core": "0.53.0", "@nivo/pie": "0.54.0", "@nivo/stream": "0.54.0" } }
让我们看看在哪里使用@nivo/core ：
npm list @nivo/core
我们看到4个@nivo/core副本（3个副本0.54.0和0.53.0 ）。 但是，如果我们将@nivo/core的次要版本更改为0.54.0 ，将消除重复项。
当前示例很简单，但是实际上，每个程序包都有更多的依赖关系，您仍然需要进一步考虑依赖关系，这增加了任务的复杂性。
再次看到捆绑包的巨大尺寸，我厌倦了手动删除重复的数据包。
通常，立即将软件包升级到最新版本是正确的，但是没有时间像往常一样更改主要版本，而且盲目地选择合适的软件包很长而且很困难。 毕竟，您需要更新package.json的依赖项版本，安装新的依赖项，然后检查构建中是否存在重复项，如果没有，则平均每次迭代重复3-4长时间。
所有这些都是单调的，需要引起注意，因此我决定实现自动化。
我想知道重复项而无需重新安装依赖项，也无需重建项目，理想情况下，cli应用程序可在10秒内显示优化选项以及项目中所有现有的重复项。
消除花费可以分为几个子任务，我们将按顺序考虑它们。
第一项任务。 给定标准重复数据删除功能，您只需在不超过100毫秒的时间内快速地通过package.json对将来的包依赖关系树进行建模。
我决定使用package-json获取有关包装的信息，并通过semver比较不同版本。
结果是一个npm软件包dependency-tree-builder ，仅通过package.json聪明地建模了bundle依赖树。
分配给单独的组件，因为也许有人会在package.json的组合任务中重用它。
第二项任务。 组合任务，有效的枚举（用于更改依赖项），对树的多个选项进行比较，以及最佳选择的选择。
我们必须以某种方式定性地比较生成的树，并且我们不得不借用熵的概念，作为对疾病的定量度量，它采用了重复副本的总和（在上面的示例中为3）。
考虑到包装重量（以KB为单位）会很好，但是不幸的是，我没有找到可以快速使用重量的包装，而每个包装可以工作约半分钟的重量，例如package-size 。 由于它们根据以下原则工作：创建具有单个依赖项的项目，建立依赖项，然后测量文件夹的总重量。 结果，我没有提出另一个标准，即重复副本的数量。
为了了解需要更改哪个程序包，请考虑重复的原因，更具体地说是源和结果。 枚举会尽可能消除重复的效果，并且由于消除了效果，因此以后也会重复。
结果 ，我们得到了一个小的cli ostap应用程序，该应用程序建议了最佳版本以减少捆绑中重复实例的数量。
它仅通过指向您项目的package.json开始。
ostap ./package.json
您也可以使用它来快速查看所有将来的需求，而无需通过仅更改package.json中的版本来重建项目。
ostap ./package.json -s
结果，在我的项目中，捆束的总重量减少了15％。
该存储库有一个快速入门部分。
如果使用路由拆分，则似乎某些捆绑包的重量有所增加，但组件的分布可能已更改。 也就是说，唯一的版本不是每个页面上的依赖项副本，而是变成了所有页面的公共捆绑包，因此您需要评估所有页面的捆绑包的总权重。
希望本文对您有所帮助。 有人会保存时间信息。 谢谢啦
再次为方便起见提供参考：
- 通过package.json对包依赖树进行包建模
Github - Dependency Optimizer用于消除捆绑中的重复项
Github
如果您有有趣的想法，请在github上发表问题，我们将进行讨论。