Nx 中 Jest 的完整配置指南從最小化 test Target 到快照管理與 CI 實踐【免費下載鏈接】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本文是一份基于 Nx Monorepo 倉庫中 packages/jest/docs/jest-examples.md 展開的 Jest 實戰指南覆蓋在 Nx 項目中配置nx/jest:jestexecutor 的最小要求、passWithNoTests與 CI 配置的推薦用法、快照更新策略以及基于nx affected的增量測試執行。讀完本文你將掌握如何為單個庫配置可復用的 Jest 測試 target如何在 CI 中安全地禁用快照寫入并理解這些選項在 packages/jest 源碼中的底層映射關系。Jest 在 Nx 中的兩種接入模式在深入配置之前先了解 Nx 中 Jest 的兩種運行方式。根據 packages/jest/PLUGIN.md 的模式檢測說明Nx 會按順序檢測先匹配者生效模式檢測方式Inference推斷nx/jest/plugin出現在 nx.json 的 plugins 數組中由 src/plugins/plugin.ts 掃描**/jest.config.{cjs,mjs,js,cts,mts,ts}自動創建 test targetExecutor執行器project.json 的 targets 中顯式聲明nx/jest:jestexecutor兩種模式可并存使用老項目通常依賴 Executor 模式顯式配置而新項目更推薦 Inference 模式由插件自動推導。本文后續內容以文檔主體——Executor 模式下的nx/jest:jest配置為主但會穿插說明兩種模式下的等價命令差異。最小配置jestConfig 是唯一必填項Jest 的可配置項很多但通過 Nx 運行 Jest你至少需要為 test target 提供jestConfig選項它指向項目的 Jest 配置文件。這是 schema.json 中聲明的唯一必填required字段{ test: { executor: nx/jest:jest, options: { jestConfig: libs/my-lib/jest.config.ts } } }關于jestConfig有兩個實現層面的細節值得注意它接受.js、.ts、.cjs、.mjs等形式的配置文件schema 中的x-completion-glob為jest.config(.js|.ts)IDE 補全會自動過濾出匹配文件。在 src/executors/jest/jest.impl.ts 中executor 會執行options.jestConfig path.resolve(context.root, options.jestConfig)即始終把相對路徑解析為相對工作區根目錄的絕對路徑后再傳給 Jest CLI。這意味著無論從哪個目錄觸發nx test都能正確定位配置文件。為什么還要一個 jest.config.tsjestConfig只是告訴 Nx/Jest 從哪里讀取配置真正的測試行為transform、moduleNameMapper、setupFiles、collectCoverageFrom 等仍然定義在 Jest 配置文件中。Nx 的 init generator 會為工作區生成jest.preset.ts與jest.config.ts項目級配置文件通常通過preset字段繼承工作區預設例如// libs/my-lib/jest.config.ts export default { displayName: my-lib, preset: ../../jest.preset.ts, setupFilesAfterEnv: [rootDir/src/test-setup.ts], // ... };passWithNoTests測試尚未就緒時不失敗在項目剛創建、測試用例還沒寫完時直接運行nx test可能因為找不到測試而失敗干擾開發節奏。此時給 options 加上passWithNoTests: true即可讓沒有測試也被視為通過{ test: { executor: nx/jest:jest, options: { jestConfig: libs/my-lib/jest.config.ts, passWithNoTests: true } } }這個選項在 schema.json 中定義為 boolean語義對應 Jest 官方的--passWithNoTestsCLI 標志在 parseJestConfig 中被透傳給 Jest 的runCLI。有趣的是如果你使用nx init或jestInitGenerator搭建 Jest這個推薦實踐已經默認內置在 init.ts 的createJestDefaultPatch中當 target 尚未定義 options 時Nx 會自動寫入options: { passWithNoTests: true }作為 workspace 級默認值。同時該函數還會配置cache: true啟用 Nx 任務緩存以及 test 的 inputspatch.inputs [ default, productionFileSet ? ^production : ^default, {workspaceRoot}/jest.preset.${presetExt}, ];這意味著 Nx 會根據項目源碼、依賴項目的 production 文件集以及 jest preset 的變化自動判斷測試緩存是否失效。快照管理本地更新CI 拒絕寫入Jest 快照snapshot是 UI 組件、序列化結果等測試中常用的斷言手段。當你修改了組件實現導致快照過期時需要更新快照nx test my-project -u其中-u是--update-snapshot的簡寫對應 schema 中的updateSnapshot字段schema.jsonexecutor 會將其映射為 Jest 的--updateSnapshot標志。你也可以結合--testNamePattern只重錄匹配的測試用例避免全局刷新快照。但并不是所有環境都允許更新快照——在 CI 中快照必須保持穩定任何過期快照都應導致構建失敗而不是被靜默改寫。為此Nx 推薦使用configurations配置變體為 test target 添加一個ci配置在其中把ci置為true{ test: { executor: nx/jest:jest, options: { jestConfig: libs/my-lib/jest.config.ts, passWithNoTests: true }, configurations: { ci: { ci: true } } } }ci選項在 schema.json 中的說明是以 CI 模式運行 Jest該模式在大多數主流 CI 環境中默認開啟會阻止快照被寫入除非顯式請求。因此 CI 流水線中應通過nx test my-project --configurationci運行這樣即使本地開發者誤用-u更新了快照CI 也會因快照差異而報紅。同樣地initgenerator 的默認 patch 也內置了更完整的 ci 配置變體init.tspatch.configurations { ci: { ci: true, codeCoverage: true, }, };即在 CI 變體中同時開啟ci: true和codeCoverage: true覆蓋率采集這也是 Nx 工作區的默認推薦組合。nx affected只測試受影響的項目在 Monorepo 中全量跑所有測試會隨倉庫規模增長而變得不可接受。Nx 的核心價值之一是affected 圖nx affected會基于 Git 變更歷史計算受影響的項目集合只對這些項目執行目標命令nx affected --targettest這條命令會對比當前分支與基線默認是 main/master找出所有受影響的 project 并逐一運行其testtarget。如果你的 test target 定義了ciconfiguration也可以結合使用nx affected --targettest --configurationci在 CI 中nx affected --targettest配合上述ci配置變體既能利用 Nx 的任務緩存跳過未變更項目又能保證快照不可被靜默更新是官方文檔推薦的標準 CI 測試范式。關于 affected 的完整語義如何指定基線、如何排除項目等可查看倉庫中關于 affected 功能的文檔與 nx.json 中的 targetDefaults 配置。從源碼看選項透傳schema 與 jest.impl.ts 的映射nx/jest:jest支持的所有選項都定義在 schema.json 中并在 parseJestConfig 里被逐一映射為 Jest CLI 的Config.Argv。除了前面提到的jestConfig、passWithNoTests、ci、updateSnapshot常用的還有Nx 選項Jest 對應說明codeCoverage別名coverage--coverage收集并輸出覆蓋率報告coverageReporters--coverageReporters指定 istanbul 覆蓋率報告器如json、html、textcoverageDirectory--coverageDirectory覆蓋率輸出目錄executor 會相對工作區根目錄解析testFile_位置參數只運行指定測試文件等價于nx test proj -- --testPathPattern...testNamePattern別名t--testNamePattern只運行名稱匹配正則的用例bail別名b--bail失敗 n 個用例后立即退出maxWorkers別名w--maxWorkers最大 worker 數接受數字或50%這類字符串runInBand別名i--runInBand單進程串行運行利于調試也常用于 CIwatch/watchAll--watch/--watchAll監聽文件變更并重跑相關/全部測試onlyChanged別名o--onlyChanged僅運行與已變更文件相關的測試需 git/hg 倉庫changedSince--changedSince基于指定分支或 commit 之后的變更運行相關測試findRelatedTests--findRelatedTests傳入逗號分隔的源文件運行覆蓋它們的測試detectOpenHandles--detectOpenHandles檢測阻止 Jest 正常退出的事件句柄forceExit--forceExit測試結束后強制退出應急手段優先排查資源泄漏testTimeout--testTimeout單個用例默認超時毫秒Jest 默認 5000testPathPatterns--testPathPatterns匹配測試路徑的正則數組testPathIgnorePatterns--testPathIgnorePatterns排除測試路徑的正則數組reporters--reporters自定義報告器如jest-junitsilent--silent阻止測試通過 console 輸出json/outputFile--json/--outputFile以 JSON 輸出結果并寫入文件showConfig--showConfig打印最終 Jest 配置后退出randomize--randomize基于 seed 打亂文件內用例順序需 jest-circusclearCache--clearCache清空 Jest 緩存目錄注意會降低后續性能logHeapUsage/detectLeaks對應 CLI 標志堆內存監控 / 實驗性的內存泄漏檢測useStderr、color/colors、verbose、testLocationInResults對應 CLI 標志輸出方向、顏色、詳情與結果定位控制幾個容易被忽視的實現細節第三方擴展參數getExtraArgsjest.impl.ts會把 schema 中未聲明、但 options 里傳入的額外鍵原樣追加到process.argv并透傳給 Jest從而支持jest-runner-groups這類第三方插件例如--groupcore。這一點有 jest.impl.spec.ts 的測試用例直接驗證。TS 配置文件支持executor 會通過環境變量強制TS_NODE_COMPILER_OPTIONS的moduleResolution: Node10、module: commonjs以兼容 jest-config 內部用 ts-node 加載.ts配置文件的機制jest.impl.ts。ESM 注意事項schema.json 中標注了nx/jest:jestexecutor已被棄用將在 Nx v24 移除官方遷移路徑是運行nx g nx/jest:convert-to-inferred切換到nx/jest/plugin推斷插件以獲得更快的配置加載與更精確的緩存輸入分析。新項目應優先使用 Inference 模式。Inference 模式下的等價操作如果你使用的是nx/jest/plugin推斷模式nx.json 的 plugins 數組包含nx/jest/plugin同一批操作有對應的命令寫法見 PLUGIN.md任務Executor 模式Inference 模式運行單個測試文件nx run proj:test --testFilepath/file.spec.tsnx test proj -- --testPathPatternpath/file.spec.ts按名稱模式運行nx run proj:test --testNamePatternpatternnx test proj -- -t pattern推斷插件的關鍵邏輯在 src/plugins/plugin.ts它通過**/jest.config.{cjs,mjs,js,cts,mts,ts}全局匹配自動發現每個項目的 test target并內置了 preset 緩存、tsconfig extends 鏈緩存等優化JestPluginOptions還支持targetName自定義 target 名、ciTargetName、disableJestRuntime關閉 jest-config/jest-runtime 加載改用自研配置加載器以提速等高級選項。總結把本文的配置串起來一個生產可用的 Jest test target 大致長這樣{ test: { executor: nx/jest:jest, options: { jestConfig: libs/my-lib/jest.config.ts, passWithNoTests: true }, configurations: { ci: { ci: true, codeCoverage: true } } } }對應的日常命令組合# 本地開發運行單個庫的全部測試 nx test my-lib # 本地開發更新快照僅限本地勿在 CI 使用 nx test my-lib -u # CI只測受影響項目禁止寫入快照并采集覆蓋率 nx affected --targettest --configurationci最小必填只有jestConfig但配合passWithNoTests、ci配置變體與nx affected你就能獲得一套既能在開發期快速迭代、又能在 CI 中穩定可靠的 Nx Jest 測試體系。這些配置項的語義、默認值與透傳邏輯均可從 schema.json、jest.impl.ts 與 init.ts 中得到源碼級印證。【免費下載鏈接】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 中 Jest 的完整配置指南：從最小化 test Target 到快照管理與 CI 實踐
Nx 中 Jest 的完整配置指南從最小化 test Target 到快照管理與 CI 實踐【免費下載鏈接】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本文是一份基于 Nx Monorepo 倉庫中 packages/jest/docs/jest-examples.md 展開的 Jest 實戰指南覆蓋在 Nx 項目中配置nx/jest:jestexecutor 的最小要求、passWithNoTests與 CI 配置的推薦用法、快照更新策略以及基于nx affected的增量測試執行。讀完本文你將掌握如何為單個庫配置可復用的 Jest 測試 target如何在 CI 中安全地禁用快照寫入并理解這些選項在 packages/jest 源碼中的底層映射關系。Jest 在 Nx 中的兩種接入模式在深入配置之前先了解 Nx 中 Jest 的兩種運行方式。根據 packages/jest/PLUGIN.md 的模式檢測說明Nx 會按順序檢測先匹配者生效模式檢測方式Inference推斷nx/jest/plugin出現在 nx.json 的 plugins 數組中由 src/plugins/plugin.ts 掃描**/jest.config.{cjs,mjs,js,cts,mts,ts}自動創建 test targetExecutor執行器project.json 的 targets 中顯式聲明nx/jest:jestexecutor兩種模式可并存使用老項目通常依賴 Executor 模式顯式配置而新項目更推薦 Inference 模式由插件自動推導。本文后續內容以文檔主體——Executor 模式下的nx/jest:jest配置為主但會穿插說明兩種模式下的等價命令差異。最小配置jestConfig 是唯一必填項Jest 的可配置項很多但通過 Nx 運行 Jest你至少需要為 test target 提供jestConfig選項它指向項目的 Jest 配置文件。這是 schema.json 中聲明的唯一必填required字段{ test: { executor: nx/jest:jest, options: { jestConfig: libs/my-lib/jest.config.ts } } }關于jestConfig有兩個實現層面的細節值得注意它接受.js、.ts、.cjs、.mjs等形式的配置文件schema 中的x-completion-glob為jest.config(.js|.ts)IDE 補全會自動過濾出匹配文件。在 src/executors/jest/jest.impl.ts 中executor 會執行options.jestConfig path.resolve(context.root, options.jestConfig)即始終把相對路徑解析為相對工作區根目錄的絕對路徑后再傳給 Jest CLI。這意味著無論從哪個目錄觸發nx test都能正確定位配置文件。為什么還要一個 jest.config.tsjestConfig只是告訴 Nx/Jest 從哪里讀取配置真正的測試行為transform、moduleNameMapper、setupFiles、collectCoverageFrom 等仍然定義在 Jest 配置文件中。Nx 的 init generator 會為工作區生成jest.preset.ts與jest.config.ts項目級配置文件通常通過preset字段繼承工作區預設例如// libs/my-lib/jest.config.ts export default { displayName: my-lib, preset: ../../jest.preset.ts, setupFilesAfterEnv: [rootDir/src/test-setup.ts], // ... };passWithNoTests測試尚未就緒時不失敗在項目剛創建、測試用例還沒寫完時直接運行nx test可能因為找不到測試而失敗干擾開發節奏。此時給 options 加上passWithNoTests: true即可讓沒有測試也被視為通過{ test: { executor: nx/jest:jest, options: { jestConfig: libs/my-lib/jest.config.ts, passWithNoTests: true } } }這個選項在 schema.json 中定義為 boolean語義對應 Jest 官方的--passWithNoTestsCLI 標志在 parseJestConfig 中被透傳給 Jest 的runCLI。有趣的是如果你使用nx init或jestInitGenerator搭建 Jest這個推薦實踐已經默認內置在 init.ts 的createJestDefaultPatch中當 target 尚未定義 options 時Nx 會自動寫入options: { passWithNoTests: true }作為 workspace 級默認值。同時該函數還會配置cache: true啟用 Nx 任務緩存以及 test 的 inputspatch.inputs [ default, productionFileSet ? ^production : ^default, {workspaceRoot}/jest.preset.${presetExt}, ];這意味著 Nx 會根據項目源碼、依賴項目的 production 文件集以及 jest preset 的變化自動判斷測試緩存是否失效。快照管理本地更新CI 拒絕寫入Jest 快照snapshot是 UI 組件、序列化結果等測試中常用的斷言手段。當你修改了組件實現導致快照過期時需要更新快照nx test my-project -u其中-u是--update-snapshot的簡寫對應 schema 中的updateSnapshot字段schema.jsonexecutor 會將其映射為 Jest 的--updateSnapshot標志。你也可以結合--testNamePattern只重錄匹配的測試用例避免全局刷新快照。但并不是所有環境都允許更新快照——在 CI 中快照必須保持穩定任何過期快照都應導致構建失敗而不是被靜默改寫。為此Nx 推薦使用configurations配置變體為 test target 添加一個ci配置在其中把ci置為true{ test: { executor: nx/jest:jest, options: { jestConfig: libs/my-lib/jest.config.ts, passWithNoTests: true }, configurations: { ci: { ci: true } } } }ci選項在 schema.json 中的說明是以 CI 模式運行 Jest該模式在大多數主流 CI 環境中默認開啟會阻止快照被寫入除非顯式請求。因此 CI 流水線中應通過nx test my-project --configurationci運行這樣即使本地開發者誤用-u更新了快照CI 也會因快照差異而報紅。同樣地initgenerator 的默認 patch 也內置了更完整的 ci 配置變體init.tspatch.configurations { ci: { ci: true, codeCoverage: true, }, };即在 CI 變體中同時開啟ci: true和codeCoverage: true覆蓋率采集這也是 Nx 工作區的默認推薦組合。nx affected只測試受影響的項目在 Monorepo 中全量跑所有測試會隨倉庫規模增長而變得不可接受。Nx 的核心價值之一是affected 圖nx affected會基于 Git 變更歷史計算受影響的項目集合只對這些項目執行目標命令nx affected --targettest這條命令會對比當前分支與基線默認是 main/master找出所有受影響的 project 并逐一運行其testtarget。如果你的 test target 定義了ciconfiguration也可以結合使用nx affected --targettest --configurationci在 CI 中nx affected --targettest配合上述ci配置變體既能利用 Nx 的任務緩存跳過未變更項目又能保證快照不可被靜默更新是官方文檔推薦的標準 CI 測試范式。關于 affected 的完整語義如何指定基線、如何排除項目等可查看倉庫中關于 affected 功能的文檔與 nx.json 中的 targetDefaults 配置。從源碼看選項透傳schema 與 jest.impl.ts 的映射nx/jest:jest支持的所有選項都定義在 schema.json 中并在 parseJestConfig 里被逐一映射為 Jest CLI 的Config.Argv。除了前面提到的jestConfig、passWithNoTests、ci、updateSnapshot常用的還有Nx 選項Jest 對應說明codeCoverage別名coverage--coverage收集并輸出覆蓋率報告coverageReporters--coverageReporters指定 istanbul 覆蓋率報告器如json、html、textcoverageDirectory--coverageDirectory覆蓋率輸出目錄executor 會相對工作區根目錄解析testFile_位置參數只運行指定測試文件等價于nx test proj -- --testPathPattern...testNamePattern別名t--testNamePattern只運行名稱匹配正則的用例bail別名b--bail失敗 n 個用例后立即退出maxWorkers別名w--maxWorkers最大 worker 數接受數字或50%這類字符串runInBand別名i--runInBand單進程串行運行利于調試也常用于 CIwatch/watchAll--watch/--watchAll監聽文件變更并重跑相關/全部測試onlyChanged別名o--onlyChanged僅運行與已變更文件相關的測試需 git/hg 倉庫changedSince--changedSince基于指定分支或 commit 之后的變更運行相關測試findRelatedTests--findRelatedTests傳入逗號分隔的源文件運行覆蓋它們的測試detectOpenHandles--detectOpenHandles檢測阻止 Jest 正常退出的事件句柄forceExit--forceExit測試結束后強制退出應急手段優先排查資源泄漏testTimeout--testTimeout單個用例默認超時毫秒Jest 默認 5000testPathPatterns--testPathPatterns匹配測試路徑的正則數組testPathIgnorePatterns--testPathIgnorePatterns排除測試路徑的正則數組reporters--reporters自定義報告器如jest-junitsilent--silent阻止測試通過 console 輸出json/outputFile--json/--outputFile以 JSON 輸出結果并寫入文件showConfig--showConfig打印最終 Jest 配置后退出randomize--randomize基于 seed 打亂文件內用例順序需 jest-circusclearCache--clearCache清空 Jest 緩存目錄注意會降低后續性能logHeapUsage/detectLeaks對應 CLI 標志堆內存監控 / 實驗性的內存泄漏檢測useStderr、color/colors、verbose、testLocationInResults對應 CLI 標志輸出方向、顏色、詳情與結果定位控制幾個容易被忽視的實現細節第三方擴展參數getExtraArgsjest.impl.ts會把 schema 中未聲明、但 options 里傳入的額外鍵原樣追加到process.argv并透傳給 Jest從而支持jest-runner-groups這類第三方插件例如--groupcore。這一點有 jest.impl.spec.ts 的測試用例直接驗證。TS 配置文件支持executor 會通過環境變量強制TS_NODE_COMPILER_OPTIONS的moduleResolution: Node10、module: commonjs以兼容 jest-config 內部用 ts-node 加載.ts配置文件的機制jest.impl.ts。ESM 注意事項schema.json 中標注了nx/jest:jestexecutor已被棄用將在 Nx v24 移除官方遷移路徑是運行nx g nx/jest:convert-to-inferred切換到nx/jest/plugin推斷插件以獲得更快的配置加載與更精確的緩存輸入分析。新項目應優先使用 Inference 模式。Inference 模式下的等價操作如果你使用的是nx/jest/plugin推斷模式nx.json 的 plugins 數組包含nx/jest/plugin同一批操作有對應的命令寫法見 PLUGIN.md任務Executor 模式Inference 模式運行單個測試文件nx run proj:test --testFilepath/file.spec.tsnx test proj -- --testPathPatternpath/file.spec.ts按名稱模式運行nx run proj:test --testNamePatternpatternnx test proj -- -t pattern推斷插件的關鍵邏輯在 src/plugins/plugin.ts它通過**/jest.config.{cjs,mjs,js,cts,mts,ts}全局匹配自動發現每個項目的 test target并內置了 preset 緩存、tsconfig extends 鏈緩存等優化JestPluginOptions還支持targetName自定義 target 名、ciTargetName、disableJestRuntime關閉 jest-config/jest-runtime 加載改用自研配置加載器以提速等高級選項。總結把本文的配置串起來一個生產可用的 Jest test target 大致長這樣{ test: { executor: nx/jest:jest, options: { jestConfig: libs/my-lib/jest.config.ts, passWithNoTests: true }, configurations: { ci: { ci: true, codeCoverage: true } } } }對應的日常命令組合# 本地開發運行單個庫的全部測試 nx test my-lib # 本地開發更新快照僅限本地勿在 CI 使用 nx test my-lib -u # CI只測受影響項目禁止寫入快照并采集覆蓋率 nx affected --targettest --configurationci最小必填只有jestConfig但配合passWithNoTests、ci配置變體與nx affected你就能獲得一套既能在開發期快速迭代、又能在 CI 中穩定可靠的 Nx Jest 測試體系。這些配置項的語義、默認值與透傳邏輯均可從 schema.json、jest.impl.ts 與 init.ts 中得到源碼級印證。【免費下載鏈接】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），僅供參考