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），僅供參考