Nx 实战入门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在包含几十个应用的仓库里每次提交都跑全量构建和测试CI 越跑越慢、越来越贵是不少团队遇到过的真实问题。Nx 是一套面向 Monorepo 的任务执行与缓存平台它能识别哪些代码真的变了、哪些任务的结果可以直接复用从而只执行受影响的范围。读完本文读者会知道如何在一分钟内让 Nx 接管现有 npm 工作区、如何通过缓存判断一次任务是否真的被执行、又该如何只测试被本次改动波及的模块并能判断自己的仓库适合从哪里入手。一个具体的痛点为什么全量跑一遍越来越撑不住设想一个仓库里有 3 个前端应用、20 个共享库。某天只改了某个库里的一处工具函数提交后 CI 却把所有应用的构建、测试、lint 从头到尾再跑一次耗时十几分钟。这十几分钟里绝大部分任务的结果和上一次完全相同——输入没变输出就不会变。Nx 的思路是先回答两个问题这次改动波及了哪些项目哪些任务的结果可以直接拿来用它通过项目之间的依赖关系图来回答第一个问题通过给任务输入做指纹哈希来回答第二个问题。这样 CI 里真正需要重跑的任务会明显减少省下的不只是时间还有机器成本和排队时间。最小上手如何让 Nx 接管一个现有项目不需要重写仓库结构。如果项目已经是一个 npm、pnpm 或 yarn 工作区直接在根目录运行npx nx init这一步之后Nx 会读取现有的package.jsonscripts把它们识别为可执行的任务并开始为这些任务的输出建立缓存。也就是说仓库里原本就存在的build、test脚本不需要任何改造就可以被 Nx 调度并缓存。如果是全新开始则用官方脚手架npx create-nx-workspacelatest它会引导选择模板React、Vue、Next.js、NestJS 等并生成带 Nx 配置的工作区。验证是否生效可以运行nx show projects看 Nx 识别到了哪些项目再运行nx run-many -t build --all跑一次全量构建。第二次运行同一命令时如果项目没有改动任务会直接命中缓存并秒级完成——这就是判断缓存工作是否正常的最直观信号。️缓存机制怎么运转任务输入如何变成指纹Nx 在执行一个可缓存任务之前会先计算它的哈希值。哈希的输入通常包括项目自身的源文件、它所依赖项目的文件、相关的工作区配置、外部依赖的版本号以及命令行参数。两次运行只要哈希一致Nx 就认为是同一个计算直接恢复上次保存的终端输出和产物文件比如 dist 目录而不是重新执行。开启方式很轻。在nx.json的targetDefaults里声明哪些目标类型参与缓存{ targetDefaults: { build: { cache: true }, test: { cache: true } } }这里有一个重要前提可缓存的任务必须是无副作用的即同样输入一定得到同样输出。比如依赖外部后端状态的 e2e 测试就不适合缓存因为后端数据会变缓存结果可能给出误导。判断方法很简单——问自己如果这次不改任何代码任务结果会不会不一样答案可能是的任务就别开缓存。远程缓存则让团队和 CI 共享同一份结果。本地执行npx nx connect关联远端之后某台机器算过的任务其他机器和 CI 节点可以直接复用新同学的 CI 首跑速度会明显好于之前。只跑受影响的模块affected 命令怎么用第二个核心能力是按变更范围执行。Nx 会对比两个 Git 提交之间的文件差异沿着项目依赖图找出所有被波及的项目只对这些项目执行任务nx affected -t test --baseorigin/main --headHEAD含义是找出相对 main 分支产生变更的项目只对它们运行 test 目标。日常提交前可以用它快速验证改动是否破坏了自己负责的模块而不必等待全量结果。批量执行用nx run-many。它按项目集合 目标类型两个维度调度例如给所有匹配libs/*的项目跑 lint多个任务之间会自动按依赖排序并行执行。理解它的两个参数就够了-t指定要跑的目标build、test、lint--all或-p指定项目范围。看懂依赖图graph 命令与实际工作流nx graph会在浏览器里打开一张交互式的项目依赖图每个节点是一个项目箭头表示依赖方向。它有两个实际用途排查为什么这个任务跑了/没跑在图里选中某个项目可以看到它的直接依赖和下游对照 affected 的输出验证 Nx 的判断是否符合直觉。识别耦合热点如果一个库被几乎所有应用依赖任何对它的改动都会触发大面积重跑这是拆分或抽象边界时的第一手信号。一个可落地的日常工作流是这样的本地用nx affected -t lint,test做提交前检查CI 里用同样的 affected 命令替代全量任务需要全量时比如改了全局配置再用run-many --all。如果怀疑缓存结果不对先别急着怀疑 Nx检查该任务是否真的满足无副作用条件或者用nx reset清除本地缓存与编译产物后重跑对比两次结果。⚡常见误区与延伸入口几个容易踩的坑提前对照检查改了代码却没重跑多半是输入配置漏了某个共享文件。Nx 的哈希只覆盖它认识到的输入全局配置文件如根目录的 babel 或 jest preset如果被任务引用却不在输入里就要手动补进配置。把有外部依赖的任务开缓存见上文缓存的是相同输入→相同输出前提不成立时缓存反而是坑。只用全量命令run-many --all适合发布前验证日常提交用 affected 才能保持反馈速度。任务定义来源混乱任务可以来自package.jsonscripts、project.json也可以由 Nx 插件从工具链配置推断。排查任务从哪来时用nx show project name查看完整定义最快。接下来可以做仓库内置文档位于 astro-docs/src/content/docs/其中缓存原理见 how-caching-works.mdoc任务执行见 run-tasks.mdoc依赖图探索见 explore-graph.mdoc。如果需要 clone 完整仓库继续研究仓库地址为 https://gitcode.com/GitHub_Trending/nx/nx 。【免费下载链接】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 实战入门：Monorepo 任务缓存与按需执行是怎么省时间的
Nx 实战入门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在包含几十个应用的仓库里每次提交都跑全量构建和测试CI 越跑越慢、越来越贵是不少团队遇到过的真实问题。Nx 是一套面向 Monorepo 的任务执行与缓存平台它能识别哪些代码真的变了、哪些任务的结果可以直接复用从而只执行受影响的范围。读完本文读者会知道如何在一分钟内让 Nx 接管现有 npm 工作区、如何通过缓存判断一次任务是否真的被执行、又该如何只测试被本次改动波及的模块并能判断自己的仓库适合从哪里入手。一个具体的痛点为什么全量跑一遍越来越撑不住设想一个仓库里有 3 个前端应用、20 个共享库。某天只改了某个库里的一处工具函数提交后 CI 却把所有应用的构建、测试、lint 从头到尾再跑一次耗时十几分钟。这十几分钟里绝大部分任务的结果和上一次完全相同——输入没变输出就不会变。Nx 的思路是先回答两个问题这次改动波及了哪些项目哪些任务的结果可以直接拿来用它通过项目之间的依赖关系图来回答第一个问题通过给任务输入做指纹哈希来回答第二个问题。这样 CI 里真正需要重跑的任务会明显减少省下的不只是时间还有机器成本和排队时间。最小上手如何让 Nx 接管一个现有项目不需要重写仓库结构。如果项目已经是一个 npm、pnpm 或 yarn 工作区直接在根目录运行npx nx init这一步之后Nx 会读取现有的package.jsonscripts把它们识别为可执行的任务并开始为这些任务的输出建立缓存。也就是说仓库里原本就存在的build、test脚本不需要任何改造就可以被 Nx 调度并缓存。如果是全新开始则用官方脚手架npx create-nx-workspacelatest它会引导选择模板React、Vue、Next.js、NestJS 等并生成带 Nx 配置的工作区。验证是否生效可以运行nx show projects看 Nx 识别到了哪些项目再运行nx run-many -t build --all跑一次全量构建。第二次运行同一命令时如果项目没有改动任务会直接命中缓存并秒级完成——这就是判断缓存工作是否正常的最直观信号。️缓存机制怎么运转任务输入如何变成指纹Nx 在执行一个可缓存任务之前会先计算它的哈希值。哈希的输入通常包括项目自身的源文件、它所依赖项目的文件、相关的工作区配置、外部依赖的版本号以及命令行参数。两次运行只要哈希一致Nx 就认为是同一个计算直接恢复上次保存的终端输出和产物文件比如 dist 目录而不是重新执行。开启方式很轻。在nx.json的targetDefaults里声明哪些目标类型参与缓存{ targetDefaults: { build: { cache: true }, test: { cache: true } } }这里有一个重要前提可缓存的任务必须是无副作用的即同样输入一定得到同样输出。比如依赖外部后端状态的 e2e 测试就不适合缓存因为后端数据会变缓存结果可能给出误导。判断方法很简单——问自己如果这次不改任何代码任务结果会不会不一样答案可能是的任务就别开缓存。远程缓存则让团队和 CI 共享同一份结果。本地执行npx nx connect关联远端之后某台机器算过的任务其他机器和 CI 节点可以直接复用新同学的 CI 首跑速度会明显好于之前。只跑受影响的模块affected 命令怎么用第二个核心能力是按变更范围执行。Nx 会对比两个 Git 提交之间的文件差异沿着项目依赖图找出所有被波及的项目只对这些项目执行任务nx affected -t test --baseorigin/main --headHEAD含义是找出相对 main 分支产生变更的项目只对它们运行 test 目标。日常提交前可以用它快速验证改动是否破坏了自己负责的模块而不必等待全量结果。批量执行用nx run-many。它按项目集合 目标类型两个维度调度例如给所有匹配libs/*的项目跑 lint多个任务之间会自动按依赖排序并行执行。理解它的两个参数就够了-t指定要跑的目标build、test、lint--all或-p指定项目范围。看懂依赖图graph 命令与实际工作流nx graph会在浏览器里打开一张交互式的项目依赖图每个节点是一个项目箭头表示依赖方向。它有两个实际用途排查为什么这个任务跑了/没跑在图里选中某个项目可以看到它的直接依赖和下游对照 affected 的输出验证 Nx 的判断是否符合直觉。识别耦合热点如果一个库被几乎所有应用依赖任何对它的改动都会触发大面积重跑这是拆分或抽象边界时的第一手信号。一个可落地的日常工作流是这样的本地用nx affected -t lint,test做提交前检查CI 里用同样的 affected 命令替代全量任务需要全量时比如改了全局配置再用run-many --all。如果怀疑缓存结果不对先别急着怀疑 Nx检查该任务是否真的满足无副作用条件或者用nx reset清除本地缓存与编译产物后重跑对比两次结果。⚡常见误区与延伸入口几个容易踩的坑提前对照检查改了代码却没重跑多半是输入配置漏了某个共享文件。Nx 的哈希只覆盖它认识到的输入全局配置文件如根目录的 babel 或 jest preset如果被任务引用却不在输入里就要手动补进配置。把有外部依赖的任务开缓存见上文缓存的是相同输入→相同输出前提不成立时缓存反而是坑。只用全量命令run-many --all适合发布前验证日常提交用 affected 才能保持反馈速度。任务定义来源混乱任务可以来自package.jsonscripts、project.json也可以由 Nx 插件从工具链配置推断。排查任务从哪来时用nx show project name查看完整定义最快。接下来可以做仓库内置文档位于 astro-docs/src/content/docs/其中缓存原理见 how-caching-works.mdoc任务执行见 run-tasks.mdoc依赖图探索见 explore-graph.mdoc。如果需要 clone 完整仓库继续研究仓库地址为 https://gitcode.com/GitHub_Trending/nx/nx 。【免费下载链接】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），仅供参考
