带有或不带有明确包装的Monorepo项目

Question

我正在研究各种Web应用程序，它们显然彼此分开。因此，想象一下我们称之为的两种产品：

• ApplicationA
• ApplicationB

这两个仍然有共同点，例如常见的util函数。 例如

export const isFunction = (value) => {
    return typeof value === "function";
};

为了轻松访问这些功能，我们已经开始使用单声道仓库，因此两个应用程序都可以导入这些功能并使用它们。 然而，建立单体仓库的常见方法是例如。使用lerna将所有内容打包处理。 这样一来，ApplicationA和ApplicationB就变成了一个包（之前已经存在），而提到的utils函数要么需要一个一个地打包（每个功能一个包），要么被上下文打包（例如array.utils，string.utils， ...）或整体上（core.utils）。

遵循此行为，无论我选择了哪种抽象级别，每个软件包在被任何应用程序使用之前都应进行捆绑和版本控制。我确实看到了显而易见且已实现的收益，这些收益至关重要，例如：

• 如果对核心v。0.0.1进行了更新并且有0.0.2可用，那么ApplicationA可能仍然可以工作，而ApplicationB可能无法工作
• 能够确定所使用的软件包使用的是哪个版本的公共软件包将确保，在决定主动更新公共软件包之前，事情不会只是停止工作

但是我看到的缺点是：

• 已使用定义的配置来捆绑公共软件包：例如如果需要针对IE进行编译，那么ApplicationA可能需要它，但ApplicationB肯定不需要
• 如果我只是导入那些导出的函数而不是包，则应用程序本身将自行处理。
• 我可以准确导入所需的功能，包括机会摇动捆绑包，如果所有东西在使用前都打包好了，则无法实现

因此，在解决更新可能损坏应用程序这一事实的过程中，当前将通用包用作子模块。这样，我就可以分支子模块并使用正确的版本，直到至少完成任何未完成的测试并且更新子模块没有风险。

实际的问题是，是否有更多的方式来处理一个单购回购交易，从而获得上述两种方案的好处？或至少消除其中一种方法的弊端。