（我在这里使用Lodash作为例子，但它可以是任何其他包）
除了将Lodash用于自己的目的之外，我的应用程序还需要从我创建的NPM包中导入JavaScript。此包中的JavaScript也依赖于Lodash。每个代码库可能已经安装了不同版本的Lodash。如果我的应用程序中的JavaScript和安装包中的JavaScript都导入了相同的Lodash函数，那么我想避免必须捆绑同一函数的两个不同版本。我知道NPM能够解决依赖关系，并且没有什么会破坏，但是我的应用程序的JavaScript包的大小将继续增长，因为每个代码库都使用来自相同库的不同版本的函数。听起来保持版本同步的唯一方法是持续监控它们并在适当时手动升级，或者直接使用已安装软件包提供的版本，而不必将其安装到我的应用程序自己的package.json中。做后者是个坏主意，还有没有更好的办法吗？
在我的公司，我们创建了一个包含大部分UI组件代码的Git存储库。此存储库还包含一个静态站点生成器，它将我们的UI组件代码转换为“生活方式指南”网站。本网站的目的是在网络上记录和展示我们的UI组件（类似于PatternLab的工作原理）。
我们还通过NPM分发此代码，以便可以跨多个项目共享。每个项目都将NPM模块作为依赖项安装，然后导入其中包含的SASS和JavaScript文件。 JavaScript已经在ES6中编写，并未捆绑或编译。我们故意选择不发布支持浏览器的代码。相反，每个项目都负责编译自己的SASS并捆绑/转换自己的JavaScript。
我们的大多数UI组件JavaScript都很简单，并且不依赖于任何第三方库，因此可以轻松导入到我们的项目中。但是，我们的一些更新，更复杂的组件依赖于Lodash等NPM软件包，这会产生问题。
显然，我们需要安装Lodash，以便静态站点生成器在Web浏览器中展示我们的Lodash-reliant组件。同样，使用NPM包的项目也需要安装Lodash，以便创建这些相同组件的实例。这迫使我们两次安装Lodash：一次在UI组件项目中，然后再次在使用NPM包的项目中。这是有问题的，因为这两个项目可能会安装不同版本的Lodash，这可能会导致兼容性问题和/或增加JavaScript包的大小。
我发现的一个解决方案是在UI组件项目中将Lodash包含在dependencies而不是devDependencies下。这样，当外部项目安装UI组件NPM模块时，Lodash将随之安装。这使得项目可以“免费”访问Lodash，而无需自行显式安装。这是可能的，因为NPM在单个平面目录层次结构中安装软件包，因此，如果您的项目直接安装软件包或者其中一个依赖项将其作为依赖项放在它自己的package.json中似乎并不重要。这消除了版本冲突，因为您不必安装包两次。
我的问题是，这是否违反了NPM的最佳做法，或者NPM的目的是什么？阅读完NPM文档和谷歌搜索后，看起来这不应该是一个问题。但是，如果我建议的是一个坏主意，我怎么能完成我想要做的事情呢？
这是一个快速的视觉辅助：
main.js
node_modules/
lodash/
foo/
bar.js
node_modules/
lodash/
main.js导入并使用Lodash。它还导入foo/bar.js，它也使用Lodash，但可能是不同的版本。这两个文件都是ES6。 main.js在被发送到浏览器之前被捆绑并转换。
答案 0 :(得分：1)
如果是您直接使用的内容，请在package.json中指定。它将被安装，但这样它将确保如果您的依赖项删除该包作为依赖项，您的项目将不会中断