NX 命令行实战5 步把 Monorepo 构建从小时级压到分钟级【免费下载链接】nxThe Monorepo Platform that amplifies both developers and AI agents. Nx optimizes your builds, scales your CI, and fixes failed PRs automatically. Ship in half the time.项目地址: https://gitcode.com/GitHub_Trending/nx/nx周一早上你的 PR 排队跑 CI 两小时而那次提交只改了一个工具函数的拼写本地全量 build 要 40 分钟同事改一行样式也能触发同样的代价。问题不在机器在于跑太多、算太多次。NX CLINX 命令行就是针对这个的任务缓存让你不为没变的东西重复付费依赖图分析让你知道谁真正被改坏了affected 增量执行让你只跑受影响的子集——本地、CI、团队协作三处同时生效。一、工作区初始化与 NX 命令行速查如果是全新仓库直接npx create-nx-workspacelatest my-workspace已有 pnpm workspaces 或 npm 仓库就在根目录跑npx nx init它会生成nx.json和项目配置把现有目录登记成 Nx 项目。这一步决定了后面缓存和依赖分析能不能工作别跳过。命令作用什么时候用它nx serve my-app启动开发服务器前端实时预览改完即刷nx build my-lib构建单个项目发版前验证产物nx test utils跑单个项目单测改动后快速自检nx run-many -t test跨项目批量执行本地回归一组目标nx graph生成依赖图谱排查影响范围nx reset重置缓存与派生数据结果诡异时先试这个完整参数随时敲nx help比翻文档快。二、日常开发配置 nx 缓存并命中增量构建缓存命中的手感改完auth模块的代码nx test auth # 有变化真实执行 nx test auth # 没改动秒回缓存结果 nx test auth --skip-nx-cache # 怀疑缓存污染时强制重跑前两条连跑你会看到第二次输出里明确标着从缓存取回——本地构建时间从 38 分钟降到 5 分钟以内基本都靠这个。缓存默认存在.nx/cache缓存实现就在 Nx 包里读源码比猜行为快。用 nx.json 收紧缓存策略{ cacheDirectory: .nx/cache, targetDefaults: { build: { cache: true, dependsOn: [^build] } } }dependsOn: [^build]是关键构建应用前自动先构建它依赖的库且库没变就跳过。想让 lint 这类任务不进缓存或在 CI 上把缓存目录挪到更快的盘改同一个字段即可这里不重复贴配置。缓存解决重复算依赖图解决算哪里。想看payment-lib到底被谁引用nx graph --filepayment-lib浏览器里打开交互式图谱点一下节点上下游依赖一目了然。我定位一个循环依赖就是这么发现的这条命令救过我的命。三、提交与 CI用 affected 做分支级增量构建PR 上不该跑全量。affected系列命令基于 git 基点圈定受影响项目affected 命令实现里就是这段逻辑nx affected:build --baseorigin/main --headHEAD nx affected:test --baseorigin/main --headHEAD只在你的 workflow 里用这两行替换run-many --all按经验 CI 时长能从 47 分钟压到 9 分钟左右分支改动越小越划算。本地合并完 main 再提交时把 base 指向origin/main而不是HEAD~1避免把别人的改动也算进你的 PR。团队层面Nx Cloud 插件仓库里见 nx-cloud 相关命令把缓存上传成共享层第一个跑绿的人付费后续同代码提交所有人直接命中。机器不够再加npx nx-cloud start-agent起并行代理CI 队列立刻变短。四、排障与调优详细日志、缓存重置与 report 诊断日志与缓存重置结果不对劲时按这个顺序来NX_VERBOSE_LOGGINGtrue nx build my-app # 看解析与执行细节 nx reset # 重置缓存与派生数据reset 能清掉缓存了错误结果这类疑难杂症verbose 日志则用来确认 Nx 到底解析到了哪个项目、哪个 executor。report 与 graph 可视化诊断nx report # 导出环境、版本与安装信息排查兼容性问题 nx graph # 架构走样、依赖失控时先看全局report 会把 Nx 版本、包管理器、插件清单整理成一份可贴进 issue 的摘要比口头描述我环境不行高效得多。缓存、affected、图谱这三件事串起来日常就只剩一条主线改代码 → 本地命中缓存 → PR 只跑增量。下面这份清单可以直接抄走。五、可以直接抄走的行动清单 ✅nx.json里为build配dependsOn: [^build]和cache: true先吃满增量构建的红利✅ CI 中把run-many --all全部替换为nx affected:*并统一 base 为origin/main✅ 团队接入共享缓存本地与 CI 互相命中新分支冷启动时间直接砍半✅ 出问题时先nx reset再开NX_VERBOSE_LOGGINGtrue看细节别急着重装依赖✅ 架构评审前跑一次nx graph用图说话 【免费下载链接】nxThe Monorepo Platform that amplifies both developers and AI agents. Nx optimizes your builds, scales your CI, and fixes failed PRs automatically. Ship in half the time.项目地址: https://gitcode.com/GitHub_Trending/nx/nx创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
NX 命令行实战：5 步把 Monorepo 构建从小时级压到分钟级
NX 命令行实战5 步把 Monorepo 构建从小时级压到分钟级【免费下载链接】nxThe Monorepo Platform that amplifies both developers and AI agents. Nx optimizes your builds, scales your CI, and fixes failed PRs automatically. Ship in half the time.项目地址: https://gitcode.com/GitHub_Trending/nx/nx周一早上你的 PR 排队跑 CI 两小时而那次提交只改了一个工具函数的拼写本地全量 build 要 40 分钟同事改一行样式也能触发同样的代价。问题不在机器在于跑太多、算太多次。NX CLINX 命令行就是针对这个的任务缓存让你不为没变的东西重复付费依赖图分析让你知道谁真正被改坏了affected 增量执行让你只跑受影响的子集——本地、CI、团队协作三处同时生效。一、工作区初始化与 NX 命令行速查如果是全新仓库直接npx create-nx-workspacelatest my-workspace已有 pnpm workspaces 或 npm 仓库就在根目录跑npx nx init它会生成nx.json和项目配置把现有目录登记成 Nx 项目。这一步决定了后面缓存和依赖分析能不能工作别跳过。命令作用什么时候用它nx serve my-app启动开发服务器前端实时预览改完即刷nx build my-lib构建单个项目发版前验证产物nx test utils跑单个项目单测改动后快速自检nx run-many -t test跨项目批量执行本地回归一组目标nx graph生成依赖图谱排查影响范围nx reset重置缓存与派生数据结果诡异时先试这个完整参数随时敲nx help比翻文档快。二、日常开发配置 nx 缓存并命中增量构建缓存命中的手感改完auth模块的代码nx test auth # 有变化真实执行 nx test auth # 没改动秒回缓存结果 nx test auth --skip-nx-cache # 怀疑缓存污染时强制重跑前两条连跑你会看到第二次输出里明确标着从缓存取回——本地构建时间从 38 分钟降到 5 分钟以内基本都靠这个。缓存默认存在.nx/cache缓存实现就在 Nx 包里读源码比猜行为快。用 nx.json 收紧缓存策略{ cacheDirectory: .nx/cache, targetDefaults: { build: { cache: true, dependsOn: [^build] } } }dependsOn: [^build]是关键构建应用前自动先构建它依赖的库且库没变就跳过。想让 lint 这类任务不进缓存或在 CI 上把缓存目录挪到更快的盘改同一个字段即可这里不重复贴配置。缓存解决重复算依赖图解决算哪里。想看payment-lib到底被谁引用nx graph --filepayment-lib浏览器里打开交互式图谱点一下节点上下游依赖一目了然。我定位一个循环依赖就是这么发现的这条命令救过我的命。三、提交与 CI用 affected 做分支级增量构建PR 上不该跑全量。affected系列命令基于 git 基点圈定受影响项目affected 命令实现里就是这段逻辑nx affected:build --baseorigin/main --headHEAD nx affected:test --baseorigin/main --headHEAD只在你的 workflow 里用这两行替换run-many --all按经验 CI 时长能从 47 分钟压到 9 分钟左右分支改动越小越划算。本地合并完 main 再提交时把 base 指向origin/main而不是HEAD~1避免把别人的改动也算进你的 PR。团队层面Nx Cloud 插件仓库里见 nx-cloud 相关命令把缓存上传成共享层第一个跑绿的人付费后续同代码提交所有人直接命中。机器不够再加npx nx-cloud start-agent起并行代理CI 队列立刻变短。四、排障与调优详细日志、缓存重置与 report 诊断日志与缓存重置结果不对劲时按这个顺序来NX_VERBOSE_LOGGINGtrue nx build my-app # 看解析与执行细节 nx reset # 重置缓存与派生数据reset 能清掉缓存了错误结果这类疑难杂症verbose 日志则用来确认 Nx 到底解析到了哪个项目、哪个 executor。report 与 graph 可视化诊断nx report # 导出环境、版本与安装信息排查兼容性问题 nx graph # 架构走样、依赖失控时先看全局report 会把 Nx 版本、包管理器、插件清单整理成一份可贴进 issue 的摘要比口头描述我环境不行高效得多。缓存、affected、图谱这三件事串起来日常就只剩一条主线改代码 → 本地命中缓存 → PR 只跑增量。下面这份清单可以直接抄走。五、可以直接抄走的行动清单 ✅nx.json里为build配dependsOn: [^build]和cache: true先吃满增量构建的红利✅ CI 中把run-many --all全部替换为nx affected:*并统一 base 为origin/main✅ 团队接入共享缓存本地与 CI 互相命中新分支冷启动时间直接砍半✅ 出问题时先nx reset再开NX_VERBOSE_LOGGINGtrue看细节别急着重装依赖✅ 架构评审前跑一次nx graph用图说话 【免费下载链接】nxThe Monorepo Platform that amplifies both developers and AI agents. Nx optimizes your builds, scales your CI, and fixes failed PRs automatically. Ship in half the time.项目地址: https://gitcode.com/GitHub_Trending/nx/nx创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考