Npm允许在项目中使用同一个包的多个版本。这是一个强大的功能。
然而，在大多数前端项目中，我认为不希望在不同版本中对相同的库具有依赖性。
在不同版本中依赖于相同的库意味着最终用户必须多次加载给定的库（作为单独的请求或作为更大的包的一部分）。
但是，如果使用npm来管理前端项目的依赖项，则可以非常快速地在不同版本中使用相同库的依赖项。
我认为在大多数情况下这是不受欢迎的，而且大部分时间我们都不了解情况。
我们最终遇到这种情况的简单案例：
在某个时间点，您在项目中安装了react-router和history：
npm i -S react-router@1.0.0-rc1
npm i -S history@1.17.0
那时react-router依赖history@1.17.0。因此，您的项目整体上只依赖于此版本的history。
稍后您决定升级到最新版本的react-router：
npm i -S react-router@2
现在react-router依赖history@2。
因此，您的项目现在依赖于history@1.17.0以及对history@2的传递依赖。
history中包含npm_modules的两个版本。
如果您使用的是像Webpack或Browerify这样的模块捆绑包，那么最终会得到一个包含两个版本history的捆绑包。
很可能你没有注意到。但是如果您注意到，您可能会将您的直接依赖关系升级为`history @ 2。
我们如何处理这个问题？
我们如何确定我们的前端项目是否依赖于不同版本的同一个库？
我们怎样才能避免使用比它们更大的捆绑包呢？
我知道技术上npm / Webpack / Browserify在包中不同版本的同一个库中包含依赖项是正确的。但我正在寻找一种方法，使其易于看到发生这种情况，以便开发人员可以采取措施来优化依赖关系。
我还在此回购中重新创建了示例：https://github.com/jbandi/npm-package-problems
答案 0 :(得分：1)
find-duplicate-dependencies工具可用于检查node_modules目录，并报告存在多个版本的软件包。
我认为在node_modules级解决问题是有道理的，因为这样做适用于WebPack和Browserify情况。