javascript - 一个 Node 模块可以利用它所依赖的 Node 模块的依赖关系吗？

Question

TL;博士; Node中是否可以实现包继承？或者有推荐的工具可以帮助解决这个问题吗？

我正在一个包含 60 多个(并且还在不断增加)网络应用程序的企业环境中工作。我们还模块化了组件，例如页眉/页脚/登录等。因此网络应用程序不需要重复代码，只需将它们作为依赖项引入即可。我们还有库模块来提供常见日志记录、建模和错误处理等功能。我们还有一个主要库，为测试和 linting 等维护提供了基础。

我想做的是访问该主库在上层模块中使用的依赖项。

lib-a   
   |   
   —> lib-b  
         |
         —> babel, chai, mocha, etc.

我想让 lib-a 从 lib-b “继承”babel、chai、mocha 等，而不必专门添加依赖项。这样我的所有库以及最终的 Web 应用程序都将具有相同的版本，并且我不必在每个 package.json 中重复相同的依赖项。我也不需要经历让 N 个团队更新 60-100 个应用程序/库/诸如此类的麻烦，并且必须处理他们提示维护问题。

我确实知道这违背了 npm 的核心，但在我们使用它的层面上，它正在成为维护难题。在这一点上，更加 DRY 肯定会带来好处。

因此，重复顶部的原始问题 - 是否可以在 Node 中实现包继承？或者有什么推荐的工具可以帮助解决这个问题吗？

我见过以下工具。有人用过吗？或者对他们有想法。还有其他吗？
https://github.com/FormidableLabs/builder
https://github.com/Cosium/dry-dry

Answer 1

这是一个坏主意。您应该假设您无法控制依赖项。还有什么方法可以改变依赖关系呢？

假设您的示例中的lib a使用mocha。由于它依赖于 lib b，而 lib b 也依赖于 mocha，因此您可以决定不在 lib a 的 package.json 中列出 mocha。

如果有人重构 lib b 不再使用 mocha，lib a 就会突然崩溃。这不好。

我们处理同样多的项目。我们使用Greenkeeper , RenovateBot ，以及一些立即将更改应用于我们所有存储库的工具。从长远来看，这对您来说可能是比违背 Node 的依赖模型更好的策略。