我们有 Nodejs 项目，其中一个是主项目。我们在其他项目中使用这个（主项目）功能。我们将我们的主项目作为带有 NPM 的包安装到其他项目中，然后使用我们需要的功能。
但是这种方式在主项目和其他项目之间产生了许多和绑定的依赖关系。每次我们更改主项目时，我们都需要在其他项目中更新它的版本，并在其他项目中安装 NPM。
请告诉我您在这种情况下的最佳做法的想法。我们如何处理主项目和其他项目之间的这种依赖关系？
谢谢
【问题讨论】：
标签： node.js architecture microservices
让我们从全局模式和措辞开始。如果将一盒函数用作其他项目的工具箱，则不应将其视为 main 项目。它只是一个需要的库。如果您愿意，可以将其称为基本库。它是一个基础，它在项目之下，而不是之上。
main 一词早已被用作程序的主入口点。因此，main 项目将是唯一的顶级包，它需要所有其他包。由于您有多个项目，所以术语 main 项目只是没有到位。
框架是一个更复杂的案例。好像不是，你在说什么。如果它是一个通用框架，我仍然会称它为 framework 而不是 main 项目。
现在已经将部分设置到适当的位置，让我们谈谈依赖关系。所有项目都依赖于这一工具箱。如果此工具箱编码良好，它将适用于所有项目。
如果它不适用于所有项目，则其中有代码，不是通用的，而是专门针对单个项目的。这部分代码是罪魁祸首。对于单个项目的特殊代码，应作为回调函数注入。然后工具箱会执行它，但是特殊代码仍然在特殊项目的代码库中，因为那里定义了回调。这种回调注入是javascript最强大的部分之一。
然后为您的代码编写测试。编写测试是干净注入和良好架构的最佳顾问。我还暗示了“依赖注入”这个术语。
所有这些听起来都很棒，但是如果你调整公共库，作为副作用，其他项目仍然会崩溃，对吧？
这不是架构问题，而是库的维护和发布周期问题。项目必须绑定到他们使用的版本。更新应以半自动方式完成，同时避免冲突。
主要和次要版本有一个常见的做法来解决这个问题。当您要求最佳实践时，答案是“语义版本控制”。 https://semver.org
API 在次要版本中得到扩展。重大更改应该只发生在主要版本中。如果升级到主要版本，所有项目都需要调整到更改后的 API。因此，中断版本应该很少见，而您应该能够毫无问题地升级到次要版本。
单个项目的完整测试覆盖有助于快速调整代码以适应库的主要版本。测试通过一次调用测试揭示了每个破坏功能。
您仍然需要一条从当前情况到令人满意的情况的迁移路径。这里的答案是 git 存储库。为每个项目创建一个基本库的分支，以保持您的业务正常运行。然后随着时间的推移将不同的分支合并为一个抽象的稳定分支。
所以我的答案有五个部分：
在你的思维方式中将“主项目”一词替换为“基础库”。
在 git 中使用不同的分支作为迁移路径。
然后了解注入，回调形式注入和依赖注入。
尽可能测试您的代码。这样做的理由更多。
最后遵循基础库的标准发布周期。
在 semver 之后，您的包将完全适用于 npm 的基于版本的依赖项管理器。
【讨论】：
base library 更改时，我必须更改其他项目中的base library 版本。这很糟糕，需要很多时间。我想消除这些类型的障碍。我们正在使用服务并使用 Kafka 管理它们。我正在寻找一种方法，看看我能否以最佳方式消除这些依赖关系。 @Blcknx
npm 的默认行为，因此是您要求的最佳实践。