Nx 23.2 来了：Oxlint、Oxfmt、更精简的 CLI 输出和更好的缓存

这个版本的发布让我非常期待！它带来了一项我特别期待的特性：Oxc 工具链已集成到 Nx 中，提供了 @nx/oxlint 和 oxfmt。但这还不是全部，让我们深入了解一下！

Oxlint 和 Oxfmt 正式引入 Nx

和很多人一样，我是 Oxc 工具链的忠实粉丝，也一直在 Nx 内部大力推动其应用。

在 23.2 版本中，我们引入了 Oxlint 和 Oxfmt。

@nx/oxlint 插件

我们将这个新插件标记为实验性功能，因为我们希望看到大家的使用情况并收集反馈，同时也因为我们有进一步改进它的计划。

它带来了一个推断插件，可以从配置文件中检测 Oxlint，还包含一个配置生成器，以及一个桥接机制，用于在 Oxlint 的 JS-plugin API 下运行 Nx 的 enforce-module-boundaries 规则。

要开始使用，请添加该插件：

nx add @nx/oxlint

这将安装 oxlint（如果你尚未安装），注册该插件，并在工作区没有 Oxlint 配置时写入根级 .oxlintrc.json。此后，每个项目都会获得一个可推断、可缓存的 lint 任务。该插件需要 Oxlint 1.70.0 或更高版本。

你无需一次性切换所有内容。Oxlint 设计为可以与 ESLint 并行运行。安装插件时，它会占用第一个可用的目标名称（若未被占用），依次遍历列表：lint、oxlint、oxlint:lint、oxlint-lint。例如：如果工作区没有其他 linter，它会使用 lint；如果 ESLint 已占用 lint，它会使用 oxlint；在迁移过程中，你可以让两者并排运行。

ESLint 仍然有用

你很可能还需要保留 ESLint 一段时间。目前 Oxlint 无法解析读取 JSON、HTML 或 Angular 模板的规则，因为没有相应的解析器，因此这些规则暂时仍需留在 ESLint 中。

运行 nx add 后，推断出的目标在整个工作区立即可用。当项目需要时，配置生成器会添加项目特定的插件。例如，React 项目可以在根配置基础上扩展 React 规则：

nx g @nx/oxlint:configuration --project=my-app --plugins=react

那么性能方面呢？

这不是正式的性能测试，只是我在一个包含 67 个可 lint 项目的 monorepo 上简单跑了一下。

运行方式	耗时
ESLint 基线	17.93s
Oxlint（原生规则）	2.74s
Oxlint + Nx boundaries	14.93s

可以看到 boundary 规则占了大量时间，因为它们要通过 Oxlint 的 JS API 桥接运行。我们目前正在研究批处理优化，这方面还有提升空间。

内置 Oxfmt 支持

以前 Prettier 是硬编码在 Nx 的 nx format 命令里的。从这个版本开始，Nx 会直接从配置文件中检测你用的是哪个格式化工具：Prettier 还是 Oxfmt。

要配置 Oxfmt，运行 @nx/js 的 init generator：

nx g @nx/js:init --formatter=oxfmt

这会添加依赖并生成一个设置了 singleQuote 的 .oxfmtrc.json。之后 nx format:write 和 nx format:check 就会自动使用它。Oxfmt 的默认配置和 Prettier 略有差异，如果你希望输出和之前保持一致，建议看一眼生成的 .oxfmtrc.json。

如果两者都配置了，Oxfmt 优先生效，同时 Nx 会警告一次，不会静默做决定。另外，没有配置格式化工具也不再报错：nx format 会给出警告并以退出码 0 结束。

性能如何？

我们在 Nx 仓库上做了一次检查，发现 Oxfmt 在检查（如 nx format:check）和写入场景下大约有 18-20 倍的提升。不过这并非严谨的性能测量，数字仅供参考。

精简日志输出，提升可读性并节省 AI token

简洁为王！这对人类很重要，对 AI agent 更是如此——输出越多，agent 需要重新读取和处理的 token 成本就越高。

因此我们做了一些体验优化：成功和命中缓存的任务现在折叠成一行，只有失败的任务才输出完整日志。

我们在 Nx 代码库上通过 nx run-many -t test 对 30 个插件包进行了测试。两次运行均实现 100% 缓存命中，因此唯一的变量是渲染方式：

• 全绿运行（31 个缓存成功）：从 205,452 字节压缩至 3,083 字节，缩减 66.6 倍。
• 混合运行（32 个成功，2 个失败）：从 326,457 字节压缩至 45,846 字节，缩减 7.1 倍。

如果你的 Agent 正在运行 Nx，它现在会自动获取折叠后的输出。在 CI 环境中也是如此，这使得 GitHub Actions 的日志更短，便于快速浏览。失败任务的输出仍会完整打印，确保你或 Agent 需要的调试信息不会缺失。

这是 static-failures-only 输出样式，Nx 现在在 CI 及其他非交互运行中默认启用。如果你想恢复完整输出，可以在单条命令中传递 --output-style=static，或者为整个 CI 任务设置环境变量 NX_DEFAULT_OUTPUT_STYLE=static。

终端 UI 的状态栏

这一轮中，Nx TUI 也迎来了一些非常棒的更新。

现在，底部新增了一条全宽状态栏。左侧显示进度计数和实时运行时长（如 63/174 (1m 23s)），点击后会打开 Nx Cloud。

另一项改进是 类 Vim 的分屏搜索。按下 space 打开详情面板后，再按 / 即可在完整的回滚日志中进行搜索，随着输入即时跳转。这遵循 Vim 式的导航逻辑：按回车键即可切换到 n/N 模式进行前后匹配。

TUI 内 PTY 中运行的任务现在也能接收鼠标和窗口大小调整事件，因此在 Nx 下运行的交互式工具会表现出与你直接在终端中运行一致的行为。

另外，如果你没注意到上个版本更新的内容，现在你可以轻松使用鼠标进行复制和粘贴了。

Nx 与多语言 Monorepo

多语言 Monorepo 正变得越来越常见。许多团队意识到端到端运行 AI Agent 的优势，同时也意识到 Monorepo 的大量维护工作现在也可以委托给 AI Agent 来处理。

Nx + TanStack + Rust

我最近研究了这一主题，并 将 Rust 引入 TanStack Monorepo。

Nx 已支持 .NET 一段时间了，而 23.2 版本优化了 @nx/dotnet 的缓存机制。

Microsoft.Extensions.ApiDescription.Server 会在构建时将 OpenAPI 文档写入 <OpenApiDocumentsDirectory> 指定的目录。此前 Nx 并不知晓这些文档是构建产物，导致任何依赖它们的任务（例如 OpenAPI 转 TypeScript 的代码生成目标）在新鲜克隆仓库或 CI 环境中，当 build 任务命中缓存回放时无法获取到这些文件。现在的 MSBuild 分析器能够自动推断这些文档并将其声明为 build 的输出，因此不再需要在 nx.json 中手动配置 outputs 覆盖项（#36788）。

我们团队的 Craigory 也深入研究了如何在拥有 .NET 后端和基于 JavaScript 前端的 Nx Monorepo 中实现全栈类型安全。完整的博客文章见 这里。

在 Agent 沙箱中运行 Nx

编程 Agent 通常运行在沙箱里，文件系统和网络访问都被限制在白名单内。这带来了一些问题，因为 Nx 的 daemon、插件 worker 和 forked 任务都要使用 unix socket，导致这些任务直接失败。

现在，nx configure-ai-agents 会写入 Claude Code 等工具所需的授权配置，覆盖 Nx 的 socket 根目录及其读写权限。

跨沙箱、worktree 和仓库克隆的更好缓存

Nx 缓存现在不仅能跨 worktree 共享，还能跨仓库克隆和 Agent 沙箱读写。

以前 worktree 共享主检出目录的 .nx 目录，路径与机器绑定。这对 worktree 有效，但没法给 Agent 沙箱提供统一的授权路径。

现在我们把 Nx 缓存和工作区数据迁移到了 ~/.nx，路径唯一且缓存键稳定，在你机器上的多个位置之间通用，彻底告别冷启动。

逐个运行迁移

在 v23 中，我们对 Nx 迁移流程做了一系列改进，包括让 Agent 参与协助。在 agentic 迁移方向上我们还有一些非常棒的改进正在开发中，尚未正式发布，敬请期待。

与此同时，这里有一个提升使用体验的小改进——现在可以更方便地单独运行某条迁移：

nx migrate --run-migration=@nx/react:update-23-2-0-add-svgr-webpack-if-used

如果迁移名称无歧义，直接写名称即可；有歧义时会报错并列出所有匹配项。

Angular 22.1 及框架更新

Nx 23.2 支持 Angular 22.1。如果你使用 Nx 的 Angular 插件（@nx/angular），运行 nx migrate latest 即可自动完成版本升级。

同时，angular-rspack 也有几处值得注意的修复：

• 构建更快，并与 esbuild application builder 的行为保持一致
• 修复 Windows 上模板或样式变更时组件重建不正确的问题
• 修复 styleUrls 不是数组时构建崩溃的问题
• Cypress 组件测试在 Angular 22.1 上恢复正常
• Webpack 相关包改为可选 peer dependencies，不用 webpack 就不会被引入

各生成器间的 Vitest 支持

坦白说，我们在各生成器中对 Vitest 的支持一直有些问题。许多生成器此前并不支持将 Vitest 用作测试运行器。

现在已修复：Vitest 可选