NxWorkspace 应用于具有多个 Angular 客户端的现有 .Net Core API

Question

我正在对 NxWorkspace 及其在现有 .Net Core 解决方案中的实现进行快速测试，其中我们有多个可以从 NxWorkspace 中受益的 Angular 应用程序。我了解在创建一个没有 .Net Core API 的新存储库时这是如何工作的，但我很难想象将 NxWorkspace 实现到我们现有的存储库中。

\n

我\xe2\x80\x99m 试图找出将 Nx 与 .Net Core（或非 JS 技术）结合使用时的最佳实践？Nx 是否必须位于根目录中，或者如果它位于下一层文件夹中是否会有影响？我\xe2\x80\x99已经完成了 NxWorkspace 视频讲座，因此我了解了 Nx 的实用性，但不知道如何将其应用于我们现有的存储库，或者是否应该与它的好处保持一致。例如：

\n

前

\n

根目录中的当前文件夹结构省略了 OpenShift、Docker 和管道工件：

\n

/dotnet-webapi\n/client1-angular\n/client2-angular\n/client3-react\n

\n

后

\n

/client-workspace 中包含 NxWorkspace 的新文件夹结构：

\n

/dotnet-webapi\n/client-workspace (NxWorkspace)\n  /apps\n    /client1-angular\n    /client2-angular\n    /client3-angular\n  /libs\n  /tools\n

\n

相对

\n

根目录中的 NxWorkspace 尽管它根本不会使 .Net Core API 受益，而且感觉就像是将 API 埋藏在 JS 生态系统中一样：

\n

/apps\n  /dotnet-webapi\n  /client1-angular\n  /client2-angular\n  /client3-angular\n/libs\n/tools\n

\n

Answer 1

我们在工作中为 Angular 应用程序利用了多个内部 .NET 核心 API，但目前我们的 monorepo 仅包含 Angular 应用程序。我们肯定已经感受到了这些的好处，并且希望最终将其扩展以容纳 .NET API。

之后的两个版本都应该可以正常工作。就我个人而言，我们推迟将 .NET 项目添加到 monorepo 中，直到出现一个类似于 Nx Community GO 插件的好插件。创建该插件后，我们将采用类似于您的第二个版本的策略，其中 api 位于 apps 目录下。

虽然您是正确的，目前它不会从中受益，但一旦创建了一个好的 .NET 插件，您就可以将其添加到workspace/nx.json 并开始获得一些好处。这些好处包括计算缓存、build:affected 等，尽管无法从应用程序堆栈的打字稿部分引用它们。