尧图网站建设 
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），仅供参考