Nrwl Nx：不同的版本号和库

Posted 2023-03-23

【中文标题】Nrwl Nx：不同的版本号和库

【英文标题】：Nrwl Nx: different version numbers and libs

【发布时间】：2018-08-14 08:56:15

【问题描述】：

我想使用 Nrwl Nx 启动一个 Angular 项目（一个项目中有多个应用程序；https://nrwl.io/nx），但我有两个问题：

如何为不同的应用程序指定不同的版本号？通常我会在package.json 中给出一个版本号，但是对于Nx，我的所有应用程序只有一个package.json。我应该把它放在环境文件中吗？还是在.angular-cli.json 文件中？

我读到：“升级到库需要更改所有实现者。”是否有任何解决方案（绕过）在不同的应用程序中使用不同版本的 lib 或 NPM 包？只有一个node_modules，但这对我的应用程序至关重要。

如您所知，Nx 项目的结构如下所示：

apps
    app1
    app2
libs
    lib1
    lib2
node_modules
package.json
.angular-cli.json
...

也许这两个问题有点基于意见（我不太确定），但是关于 Nrwl Nx 的文章很少，答案也可以帮助其他人。谢谢。

【问题讨论】：

您好，您有什么解决办法吗？我会说我有同样的“问题”。就我而言，app1 和 app2 可以使用不同版本的 lib1。

@BrunoBruzzano 嗨，不是真的。也许看看这个：github.com/nrwl/nx/issues/309

大声笑，我已经在那里问过了，但我根本没有得到任何答复:-(

这些答案都不是真正的答案，而只是“不要那样做”cmets。不幸的是，这对于很多情况来说是不够的。例如，我有一个包含多个小型 API 的 monorepo。这些中的每一个都需要在语义上进行版本控制，这意味着共享版本对于单独的更改没有意义。我很想听听任何对所提问题有实际解决方案的人的意见。

【参考方案1】：

从技术上讲，不可能为 NX 工作区中的不同应用程序指定不同的版本号，因为 NX 工作区基于 monorepo（这是领先的 IT 公司使用的技术，如 google、Facebook 等）。

是的，您可以通过重组 NX 工作区为不同的应用程序指定不同的版本号，但从技术上讲，它不会是 monorepo NX 工作区。

【参考方案2】：

我在这里有一些想法。我每天都在使用 NX Extensions，恕我直言，“这不是单声道回购方式”作为一种理想方式很好，但在实践中却失败了。您迟早会想要对库进行重大更改，并且您不希望应用程序中的所有测试在您执行此操作时都失败（阻止您发布等，您可能没有时间来清理）。这可能不是 OP 所要达到的目的，但我认为这些解决方案可能会有所帮助。我都试过了，它们似乎有效。

请注意，我知道谷歌的方式（我在那里工作）。我在我从事的第一个项目中遇到了这个问题。他们的开发环境提供了“如果您可以在每个应用程序中使用不同的 package.json...”的模拟，因此将 NX 与 Google 的内部系统以绝对 1:1 的比例进行比较有点不对劲。

限定符：这不是“答案”。它只是分享了我克服这些问题的一些方法。

分支整个 repo，称之为版本。做出重大改变，看到一切都崩溃了。修复一切，从 master 更新，看起来不错，合并它。可选：从此分支发布。

“devbranch”的东西适用于大多数“破坏性的 lib 更改”类型的东西。

在 tsconfig.json 中，如果您为库 ​​(@myorg/blah) 起别名，您的应用将指向您配置的路径。在 master 中，构建你的库（ng-packagr）。使用输出配置，您可以随意调用 dist（@myorg/blah-v1、v2、任意数量）。将 tsconfig 指向它（tsconfig 将指向非构建路径）。 Master 现在将使用一个锁定的、已知的 lib 版本（只是不要通过更改重新构建它）。您现在可以随意滥用您的主库。为了保持“一切都在 master 工作”的心态，您将分支 master，然后进行此更改，这将允许您独立于使用它的应用程序处理 lib，而 master 不受影响。

构建你的库（版本化，并假设 ng-packagr），npm 打包它（你现在有一个 tarball），用它做你想做的事。分支大师，从 tsconfig 中删除路径条目，将安装条目添加到 package.json（您可以从文件安装），您的应用程序应该选择它（同样，导入别名应该匹配）。您还可以在 master（已知的工作版本为 tarball）中进行安装，然后根据需要再次滥用您的库。

我对后一种解决方案进行了一些测试，发现它有效，但如果您不必打包 tarball 并弄乱 package.json，何必费心呢。不过，这是个不错的选择，而且它不会导致无法重建库的缺点（因为除非您更改输出目标，否则您将覆盖已知的工作版本）。

使用这些想法，我几乎可以让我们摆脱任何重大变更的困境，并至少提供任何给定库的另一个已知工作版本。

不过，我也会把这些放在那里：

mono repo 的主要好处是它迫使您避免招致多个 lib 版本导致的技术债务，如果您在任何时间段内放弃它，这将是严重的。如果你放得够久，迟早你会遇到整个 Angular 版本的问题，这是你想要避免的问题。

如果您的应用程序需要大量漂移，恕我直言，您最好创建一个新的存储库，将代码转储到其中，从您的主存储库中擦除它，等到它会成形，并在准备好时放回原处（如果有的话）。

而且，请记住，当您在图书馆工作时，您需要有一些不同的想法。它是共享代码，每次您对其进行更改时，它都不会被破坏。与其重命名该输入，不如创建另一个输入并将其指向原始输入（向后兼容），诸如此类。装饰器模式，所有这些。库中的重大更改不应该是随便提交的事情。

希望对您有所帮助。

【讨论】：

我希望它有所帮助。我认为没有理由编辑它。如果你要编辑，请给我一个理由。

【参考方案3】：

正如 JBecton 已经回答的那样，“Nx 方式”是拥有一个 package.json。

在您的情况下，您需要将您的应用版本控制与 mono-repo 版本控制解除关联。

角度生成的环境*.ts 文件是执行此操作的正确位置。

【讨论】：

我得说这对我来说是最有意义的。虽然我看到了拥有相同 node_modules 和 package.json 的价值，但绝对需要为每个应用程序独立管理版本号的用例。

【参考方案4】：

Nx 使用 MonoRepo 方法，因此您的应用程序和库都将是相同的版本。 https://nrwl.io/nx/why-a-workspace

【参考方案5】：

根据 Monorepo 的概念，所有应用程序都应该放在同一个保护伞中，这意味着在同一个存储库中，并且要在同一个 monorepo 中维护多个应用程序，使用不同的版本是非常困难的。 还拥有一个包文件确保在更新工作区时所有应用程序都默认更新。 这应该是任何组织在同一版本中拥有所有应用程序的标准。