Nx 23.2 已发布：Oxlint、Oxfmt、更简洁的 CLI 输出以及改进的缓存机制
我一直非常期待这个版本！这次带来了我个人最喜欢的一个功能：Oxc 工具链登陆 Nx，推出了 @nx/oxlint 和 oxfmt。除此之外还有更多新内容，让我们一探究竟！
Oxlint 和 Oxfmt 登陆 Nx
和很多人一样，我一直很喜欢 Oxc 工具链，并且在 Nx 内部一直大力推广它。
在 23.2 版本中，Oxlint 和 Oxfmt 正式落地了。
@nx/oxlint 插件
这个新插件目前以实验性状态发布，一方面是希望大家都来试用并反馈意见，另一方面我们还有后续的改进计划。
它包含一个推断插件（inference plugin），能从你的配置文件中检测到 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 还会再留一段时间。目前 Oxlint 无法解析读取 JSON、HTML 或 Angular 模板的规则，因为还没有相应的解析器，所以这些规则暂时还得交给 ESLint 处理。
运行 nx add 之后，推断目标立即在整个工作区可用。当某个项目需要特定配置时，配置生成器可以添加项目级别的插件。例如，一个 React 项目可以通过以下命令在根配置的基础上扩展 React 规则：
nx g @nx/oxlint:configuration --project=my-app --plugins=react性能如何？
这不算正式的性能测试，但我在一个包含 67 个可 lint 项目的 monorepo 上试了一下。
| Run | Time |
|---|---|
| ESLint baseline | 17.93s |
| Oxlint, native rules | 2.74s |
| Oxlint with Nx boundaries | 14.93s |
可以看到，由于边界规则需要通过 Oxlint 的 JS API 桥接来运行，因此消耗了大量时间。通过批量处理任务有望进一步改善，这正是我们目前正在研究的方向。
内置 Oxfmt 支持
此前，Nx 通过 nx format 命令硬编码支持 Prettier。从本次发布开始，Nx 会直接从配置文件中检测正在使用的格式化工具：Prettier 或 Oxfmt。
要配置 Oxfmt，请运行 @nx/js 初始化生成器：
nx g @nx/js:init --formatter=oxfmt这会添加依赖项，并生成一个将 singleQuote 设置为 true 的 .oxfmtrc.json 文件。之后，nx format:write 和 nx format:check 就会自动使用它。Oxfmt 的默认设置与 Prettier 略有差异，如果你希望保持与之前一致的输出效果，建议查看一下生成的 .oxfmtrc.json。
如果同时配置了两者，Oxfmt 优先，并且 Nx 会发出一次警告以避免静默选择。此外，未配置任何格式化工具也不再报错：nx format 会发出警告并以 0 退出。
性能如何？
我们在 Nx 仓库上做了一个测试，发现 Oxfmt 在 check（如 nx format:check）和 write 操作之间，性能提升了大约 18 到 20 倍。请注意，这并非严格意义上的基准测试，因此仅供参考。
精简日志输出，提升可读性并降低 AI token 开销
简洁为王！这对人类开发者很重要，对 AI agent 更是如此。输出越多，token 成本越高，因为 AI agent 需要重新读取和处理这些内容。
因此，我们做了一些可用性改进：成功执行和命中缓存的任务现在将折叠为一行显示，只有失败的任务才会打印完整输出。
我们在 Nx 代码库上测量了该效果：对 30 个插件包运行 nx run-many -t test，两次均为 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 job 中设置 NX_DEFAULT_OUTPUT_STYLE=static。
终端 UI 的状态栏
本期 Nx TUI 带来了一些很酷的新更新。
底部新增了一行全宽状态栏。左侧是进度计数与实时运行时长（63/174 (1m 23s)），点击可打开 Nx Cloud。
space 打开详情面板后，再按 /，就可以在完整的滚动日志中搜索，边输入边增量跳转。这遵循 Vim 风格的按键习惯：按 Enter 后可以用 n/N 在匹配项之间导航。
现在，TUI 的 pty 中运行的任务也能接收鼠标和窗口大小变化事件了，因此在 Nx 下运行的交互式工具，其表现和直接在你的终端里运行时一样。
另外，如果你错过了上一个版本的更新：现在可以直接用鼠标光标方便地复制粘贴了。
Nx 与多语言 monorepo
多语言 monorepo 正变得越来越普遍。很多团队意识到让 AI agent 端到端工作的优势，monorepo 的不少维护工作现在也可以交给 AI agent 来做。
Nx + TanStack + Rust最近在 往 TanStack monorepo 中添加 Rust 时，我深入研究了这个话题。
Nx 对 .NET 的支持已经有一段时间了，而 23.2 版本进一步改进了 @nx/dotnet 的缓存能力。
Microsoft.Extensions.ApiDescription.Server 会在构建时把 OpenAPI 文档写入 <OpenApiDocumentsDirectory> 指定的目录。此前 Nx 并不知道这些文档是构建产物，因此在全新克隆或 CI 环境中，只要 build 从缓存重放，依赖这些文档的任务（比如 OpenAPI 到 TypeScript 的代码生成目标）就会拿不到内容。现在 MSBuild 分析器会自动推断并将它们声明为 build 输出，你不再需要在 nx.json 中手动配置 outputs 覆盖项了（#36788）。
我们团队的 Craigory 还深入探讨了如何在 .NET 后端加 JavaScript 前端的 Nx monorepo 中实现全栈类型安全，完整内容见这篇博客文章。
在 agent 沙箱中运行 Nx
Coding agent 通常在沙箱中运行，文件系统和 socket 访问都被限制在白名单内。这带来了一些问题，因为 Nx 会为 daemon、plugin worker 和 forked 任务打开 unix socket，导致这些任务失败。
现在 nx configure-ai-agents 会写入 Claude Code 等工具所需的许可配置，涵盖 Nx 的 socket 根目录及其读写权限。
更好的缓存：跨沙箱、worktree 和仓库克隆
Nx 缓存现在不仅可以在多个 worktree 之间共享，还能在仓库克隆和 agent 沙箱之间读写。
此前 worktree 共享主 checkout 的 .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 已经可以选了 e