我在质疑为什么我们需要这样做。 我们正在解决这个问题吗？ 据我所知，我们拥有的工具现在可以工作了。 将所有工具重写为 nrwl 插件时，我们会获得什么好处？

不是重写——更多的是它是如何集成到 nx 工作区中的。 它应该更像是一个将库转换为插件的库。 然后我们就可以摆脱构建我们自己的构建器的“hacky”方式。
以tsc --outdir /node_modules/dynatrace/barista-builders为例

我们应该始终遵循 nx 的指导方针，因为它是一个自以为是的文件夹结构，否则工具将无法按预期工作

如果我在这里错了，请纠正我，但目前该工具确实按预期工作，不是吗？

才不是。 我们遇到的问题是文件没有从我们粉碎依赖关系图的工具中获取和导入。 我们的工具不是库，而是 nrwl/nx 意义上的工具。 它们是插件，所以我们应该将它们视为一个。 这应该在@ffriedl89工作区重构之后解决。

好吧。 据我了解@ffriedl89给我的解释：

• 我们不得不将所有工具移动到 #570 的 libs 文件夹中，因为 nx 在它们的边界 linting 规则中有apps和libs硬编码路径
• 因为我们现在已经将工具移到了库中，所以 nx 的其他 linting 规则失败了，因为它们不允许在他们的 libraryRoot 中添加额外的文件（即 Dockerfile 等。_files 我们在某些工具场合中依赖的文件_）
• Nx 为版本 9 提供了一个新的解决方案，因为他们显然注意到，需要额外的工具。 他们这样做的方法是将工具（不应被视为库）添加到 linting 不太严格的插件文件夹中。

@tomheller完美总结：D

此问题已过时，因为它已打开 30 天而没有任何活动。 删除陈旧的标签或评论，否则这将在 5 天内关闭

此问题已过时，因为它已打开 90 天且没有任何活动。 删除陈旧的标签或评论，否则这将在 5 天内关闭