Nx 中 nx/js:tsc 执行器实战Transformer 插件与批量构建模式深度解析【免费下载链接】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/js:tsc是 Nx 生态中负责使用 TypeScript 编译构建的核心执行器executor它封装了 tsc 编译能力并与 Nx 的任务编排、缓存、依赖图深度集成。本文以 packages/js/docs/tsc-examples.md 为骨架完整讲解两个高阶实战主题如何通过transformers选项挂载 TypeScript Transformer 插件如 NestJS Swagger 插件、AutoMapper 插件以及自 Nx 16.6.0 引入的 batch 批量执行模式--batch的原理与最佳实践。读完本文你将能直接在 Nx 工作区中配置 Transformer 插件加速代码生成并通过批量模式让多项目构建获得数量级提升。一、nx/js:tsc执行器速览nx/js:tsc位于nx/js插件包中其执行器实现位于 packages/js/src/executors/tsc/tsc.impl.ts批处理实现位于 packages/js/src/executors/tsc/tsc.batch-impl.ts。它的职责包括按tsConfig编译 TypeScript 源码到outputPath复制assets中声明的静态资源生成或更新输出目录下的package.json可通过generatePackageJson控制通过checkDependencies解析项目依赖并自动将依赖项目的产物映射进临时 tsconfigtsc.impl.ts支持watch增量监听模式与 batch 批量构建模式。执行器的完整选项定义在 packages/js/src/executors/tsc/schema.json其中required字段为main、outputPath、tsConfig三项也就是说任何一个nx/js:tsc目标至少需要指定入口文件、输出目录和 tsconfig 路径。文档 tsc-examples.md 通过examplesFile字段被 schema 声明引用专门收录该执行器的高阶用法示例。二、使用 TypeScript Transformer 插件2.1 配置示例nx/js:tsc可以通过transformers选项直接运行 TypeScript Transformer 插件。典型配置如下对应文档示例位于 tsc-examples.md{ build: { executor: nx/js:tsc, options: { outputPath: dist/libs/ts-lib, main: libs/ts-lib/src/index.ts, tsConfig: libs/ts-lib/tsconfig.lib.json, assets: [libs/ts-lib/*.md], transformers: [ nestjs/swagger/plugin, { name: automapper/classes/transformer-plugin, options: {} } ] } } }transformers数组中的每一项支持两种写法见 schema.json 中transformerPattern定义写法说明字符串形式直接写插件包名如nestjs/swagger/plugin等效于{ name: ..., options: {} }对象形式{ name: 插件包名, options: { ... } }用于给插件传递额外配置参数options为任意 JSON 对象additionalProperties: true其中name为必填项这种字符串/对象混合的宽松设计使得配置既简洁又具备扩展性无需传参的插件一行即可需要传参的插件用对象表达。2.2 底层加载与执行机制配置只是入口真正执行 Transformer 的链路可以从源码还原出来在 tsc.impl.ts 中createTypeScriptCompilationOptions会调用getCustomTrasformersFactory(normalizedOptions.transformers)把transformers配置转换为一个给定ts.Program返回ts.CustomTransformers的工厂函数工厂函数实现位于 packages/js/src/executors/tsc/lib/get-custom-transformers-factory.ts它调用loadTsTransformers加载插件并将插件暴露的before/after/afterDeclarations三类钩子分别映射到 TypeScript 的CustomTransformers对应阶段before源码在类型检查/生成前先经过转换常用于装饰器元数据生成、路径别名等afterAST 转译后、输出 JS 前常用于代码精简、格式加工afterDeclarations对.d.ts声明文件生成过程施加转换。真正的插件解析逻辑在 packages/js/src/utils/typescript/load-ts-transformers.ts它遍历node_modulesprocess.cwd()/node_modules与模块解析路径通过require.resolve定位插件并require加载若主导出缺少 transformer 钩子则回退尝试default导出插件找不到或格式无法识别时只记录logger.warn而不会中断构建。值得说明的是loadTsTransformers对插件形态做了兼容处理源码注释与 load-ts-transformers.spec.ts 的测试用例均可佐证标准形态插件导出{ before?, after?, afterDeclarations? }钩子函数函数式形态插件直接导出一个函数或导出{ before: Function }等仅含函数属性的对象加载器会自动包装适配未知形态无法识别时打印告警并跳过。在批量模式下自定义 Transformer 同样受支持批处理实现会把每个任务的transformers选项写入项目上下文见 tsc.batch-impl.ts并在每次项目编译时通过getCustomTrasformersFactory(projectContext.transformers)(project.getProgram())注入编译器见 packages/js/src/executors/tsc/lib/typescript-compilation.ts。2.3 应用场景Transformer 插件最常见的用途是在编译期对代码做元编程式转换典型如文档示例中出现的nestjs/swagger/plugin自动从 TS 类型推断并生成 Swagger 文档元数据省去手写ApiProperty注解automapper/classes/transformer-plugin自动生成 AutoMapper 的映射代码避免手写映射函数。这类插件若放在tsc之外单独运行通常需要额外的构建步骤和 CLI 参数而通过transformers配置即可与普通 tsc 编译无缝合并一次构建同时产出 JS、声明文件与转换产物。三、Batch 批量执行模式3.1 是什么自Nx 16.6.0起nx/js:tsc支持在单个进程中运行多个构建任务的 batch 实现。批量模式直接使用 TypeScript 官方为项目引用Project References提供的增量构建 API因此在构建任务图越大时相对默认实现的性能提升越显著——这正是文档强调的核心收益点。nx build ts-lib --batch3.2 注意事项务必阅读文档对该特性标注了三条关键前提实验性功能batch 模式目前处于实验阶段使用时需评估风险依赖要求使用 batch 模式构建某项目时其所有依赖项目隐式依赖除外必须可构建buildable且同样使用nx/js:tsc执行器构建不支持prepend选项从源码看compileTypescriptSolution会显式跳过已废弃的prepend编译器选项TS 5.5 起已彻底移除遇到时仅记录告警见 typescript-compilation.ts。3.3 底层原理从源码角度拆解 batch 模式的实现核心链路如下tsc.batch-impl.ts 首先对任务图内的每个任务做选项归一化normalizeTasksOptions并统一处理clean若某任务设置了clean: true会先递归清空其输出目录接着为每个任务生成内存中的临时 tsconfiggetProcessedTaskTsConfigs将任务间的依赖关系以 TypeScript 项目引用的形式串联起来核心编译函数compileTypescriptSolutiontypescript-compilation.ts使用ts.createSolutionBuilder非 watch 模式或ts.createSolutionBuilderWithWatchwatch 模式构建解决方案通过getNextInvalidatedProject()逐个取出需要编译的项目由于整个解决方案在同一进程内共享TypeScript 的增量缓存.tsbuildinfo和程序缓存得以复用从而避免默认实现中每个任务独立起一个 tsc 进程、重复解析与类型检查的开销。3.4 性能优化clean: false与.tsbuildinfo文档给出了一条明确的性能优化建议为了发挥批量模式的增量优势可把clean选项设为false{ build: { executor: nx/js:tsc, options: { outputPath: dist/libs/ts-lib, main: libs/ts-lib/src/index.ts, tsConfig: libs/ts-lib/tsconfig.lib.json, assets: [libs/ts-lib/*.md], clean: false } } }原因在于clean默认值为true见 schema.json构建前会清空输出目录导致 TypeScript 生成的.tsbuildinfo增量缓存文件一并丢失增量构建的关键优化也随之失效。设置clean: false后tsc的增量构建机制可以跨构建复用编译状态大幅缩短重复构建耗时。需要强调的是文档明确指出这不是硬性要求——即使不关闭cleanbatch 实现依然有进程复用、程序共享等其他重要优化收益。此外从 tsc.batch-impl.ts 可以看到批处理还处理了任务被判定为受影响但实际 TS 项目无文件变更的边界场景如命中缓存或--skip-nx-cache此时会跳过 TypeScript 编译但继续完成资产复制与package.json更新确保任务结果完整上报。四、常用选项速查除transformers与clean外schema.json 还定义了以下常用选项供配置nx/js:tsc目标时参考选项类型默认值说明mainstring-主入口文件路径必填支持.js/.ts/.jsx/.tsxoutputPathstring-构建产物输出目录必填tsConfigstring-TypeScript 配置文件路径必填rootDirstring项目根目录指定编译的 rootDir不设置时使用项目根目录outputFileNamestring-主文件相对outputPath的输出文件名assetsarray[]静态资源列表支持字符串或{glob, input, output, ignore, includeIgnoredFiles}对象watchbooleanfalse文件变更时自动重新构建cleanbooleantrue构建前清空输出目录transformersarray[]TypeScript Transformer 插件列表generatePackageJsonbooleantrue是否在输出目录生成package.jsongenerateExportsFieldbooleanfalse是否更新输出package.json的exports字段generatePackageJsonfalse时忽略additionalEntryPointsarray-追加到exports字段的额外入口点同上受generatePackageJson约束generateLockfilebooleanfalse生成与工作区锁文件匹配的锁文件保证依赖版本一致includeIgnoredAssetFilesbooleanfalse复制资产时是否包含被.gitignore/.nxignore忽略的文件注意这些文件不参与任务哈希计算需要额外配置inputs才能被 Nx 缓存正确跟踪值得留意的是assets的对象形式当配置为对象时glob、input、output三项均为必填input默认指向项目根目录output为产物目录内的绝对路径schema.json。这与文档示例中assets: [libs/ts-lib/*.md]的字符串简写形式互为补充字符串适合从项目根目录按 glob 复制到输出根目录的常见场景对象形式则适合需要精确控制来源目录、忽略规则与输出位置的复杂场景。五、与 Watch 模式及模块格式的协同在 watch 模式下watch: true默认实现tsc.impl.ts要求 Nx Daemon 处于启用状态否则资产与package.json不会随文件变更自动更新构建时会给出警告。当 Daemon 启用时执行器会监听资产变更与项目package.json变更并在收到SIGINT/SIGTERM时优雅释放监听器。另一个容易被忽视的细节是模块格式判定determineModuleFormatFromTsConfigtsc.impl.ts会读取编译后的 tsconfig 选项来决定输出格式并写入生成的package.jsonmodule为NodeNext时还需结合项目package.json的type字段判断type: module输出 ESM否则为 CJSmodule为ES2015/ES2020/ES2022/ESNext时判定为 ESM其余情况判定为 CJS。这意味着在开启generatePackageJson的前提下Nx 会自动根据你的 tsconfig 与 package.json 推断产物格式你无需手写输出包的类型字段。在 batch 模式下同一套判定逻辑同样作用于每个任务tsc.batch-impl.ts保证批量构建产出的包信息与单任务构建完全一致。六、小结围绕 packages/js/docs/tsc-examples.md 这份示例文档本文完整还原了nx/js:tsc的两个进阶用法Transformer 插件通过transformers选项字符串或{name, options}对象挂载编译期转换插件底层由 load-ts-transformers.ts 统一加载并按before/after/afterDeclarations三个阶段注入兼容标准与函数式两种插件导出形态Batch 批量构建自 Nx 16.6.0 起可用--batch让多个nx/js:tsc任务在单进程内共享 TypeScript 增量构建能力任务图越大收益越明显配合clean: false保留.tsbuildinfo可进一步放大增量优化效果同时需满足依赖项目均可构建且同为 tsc 执行器的前置条件。对于 Nx 工作区中大量使用nx/js:tsc构建库的场景这两个特性组合起来既能让复杂元编程插件与常规编译无缝融合又能在多包构建时显著压缩整体耗时是值得投入的优化方向。【免费下载链接】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 中 nx/js:tsc 执行器实战Transformer 插件与批量构建模式深度解析【免费下载链接】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/js:tsc是 Nx 生态中负责使用 TypeScript 编译构建的核心执行器executor它封装了 tsc 编译能力并与 Nx 的任务编排、缓存、依赖图深度集成。本文以 packages/js/docs/tsc-examples.md 为骨架完整讲解两个高阶实战主题如何通过transformers选项挂载 TypeScript Transformer 插件如 NestJS Swagger 插件、AutoMapper 插件以及自 Nx 16.6.0 引入的 batch 批量执行模式--batch的原理与最佳实践。读完本文你将能直接在 Nx 工作区中配置 Transformer 插件加速代码生成并通过批量模式让多项目构建获得数量级提升。一、nx/js:tsc执行器速览nx/js:tsc位于nx/js插件包中其执行器实现位于 packages/js/src/executors/tsc/tsc.impl.ts批处理实现位于 packages/js/src/executors/tsc/tsc.batch-impl.ts。它的职责包括按tsConfig编译 TypeScript 源码到outputPath复制assets中声明的静态资源生成或更新输出目录下的package.json可通过generatePackageJson控制通过checkDependencies解析项目依赖并自动将依赖项目的产物映射进临时 tsconfigtsc.impl.ts支持watch增量监听模式与 batch 批量构建模式。执行器的完整选项定义在 packages/js/src/executors/tsc/schema.json其中required字段为main、outputPath、tsConfig三项也就是说任何一个nx/js:tsc目标至少需要指定入口文件、输出目录和 tsconfig 路径。文档 tsc-examples.md 通过examplesFile字段被 schema 声明引用专门收录该执行器的高阶用法示例。二、使用 TypeScript Transformer 插件2.1 配置示例nx/js:tsc可以通过transformers选项直接运行 TypeScript Transformer 插件。典型配置如下对应文档示例位于 tsc-examples.md{ build: { executor: nx/js:tsc, options: { outputPath: dist/libs/ts-lib, main: libs/ts-lib/src/index.ts, tsConfig: libs/ts-lib/tsconfig.lib.json, assets: [libs/ts-lib/*.md], transformers: [ nestjs/swagger/plugin, { name: automapper/classes/transformer-plugin, options: {} } ] } } }transformers数组中的每一项支持两种写法见 schema.json 中transformerPattern定义写法说明字符串形式直接写插件包名如nestjs/swagger/plugin等效于{ name: ..., options: {} }对象形式{ name: 插件包名, options: { ... } }用于给插件传递额外配置参数options为任意 JSON 对象additionalProperties: true其中name为必填项这种字符串/对象混合的宽松设计使得配置既简洁又具备扩展性无需传参的插件一行即可需要传参的插件用对象表达。2.2 底层加载与执行机制配置只是入口真正执行 Transformer 的链路可以从源码还原出来在 tsc.impl.ts 中createTypeScriptCompilationOptions会调用getCustomTrasformersFactory(normalizedOptions.transformers)把transformers配置转换为一个给定ts.Program返回ts.CustomTransformers的工厂函数工厂函数实现位于 packages/js/src/executors/tsc/lib/get-custom-transformers-factory.ts它调用loadTsTransformers加载插件并将插件暴露的before/after/afterDeclarations三类钩子分别映射到 TypeScript 的CustomTransformers对应阶段before源码在类型检查/生成前先经过转换常用于装饰器元数据生成、路径别名等afterAST 转译后、输出 JS 前常用于代码精简、格式加工afterDeclarations对.d.ts声明文件生成过程施加转换。真正的插件解析逻辑在 packages/js/src/utils/typescript/load-ts-transformers.ts它遍历node_modulesprocess.cwd()/node_modules与模块解析路径通过require.resolve定位插件并require加载若主导出缺少 transformer 钩子则回退尝试default导出插件找不到或格式无法识别时只记录logger.warn而不会中断构建。值得说明的是loadTsTransformers对插件形态做了兼容处理源码注释与 load-ts-transformers.spec.ts 的测试用例均可佐证标准形态插件导出{ before?, after?, afterDeclarations? }钩子函数函数式形态插件直接导出一个函数或导出{ before: Function }等仅含函数属性的对象加载器会自动包装适配未知形态无法识别时打印告警并跳过。在批量模式下自定义 Transformer 同样受支持批处理实现会把每个任务的transformers选项写入项目上下文见 tsc.batch-impl.ts并在每次项目编译时通过getCustomTrasformersFactory(projectContext.transformers)(project.getProgram())注入编译器见 packages/js/src/executors/tsc/lib/typescript-compilation.ts。2.3 应用场景Transformer 插件最常见的用途是在编译期对代码做元编程式转换典型如文档示例中出现的nestjs/swagger/plugin自动从 TS 类型推断并生成 Swagger 文档元数据省去手写ApiProperty注解automapper/classes/transformer-plugin自动生成 AutoMapper 的映射代码避免手写映射函数。这类插件若放在tsc之外单独运行通常需要额外的构建步骤和 CLI 参数而通过transformers配置即可与普通 tsc 编译无缝合并一次构建同时产出 JS、声明文件与转换产物。三、Batch 批量执行模式3.1 是什么自Nx 16.6.0起nx/js:tsc支持在单个进程中运行多个构建任务的 batch 实现。批量模式直接使用 TypeScript 官方为项目引用Project References提供的增量构建 API因此在构建任务图越大时相对默认实现的性能提升越显著——这正是文档强调的核心收益点。nx build ts-lib --batch3.2 注意事项务必阅读文档对该特性标注了三条关键前提实验性功能batch 模式目前处于实验阶段使用时需评估风险依赖要求使用 batch 模式构建某项目时其所有依赖项目隐式依赖除外必须可构建buildable且同样使用nx/js:tsc执行器构建不支持prepend选项从源码看compileTypescriptSolution会显式跳过已废弃的prepend编译器选项TS 5.5 起已彻底移除遇到时仅记录告警见 typescript-compilation.ts。3.3 底层原理从源码角度拆解 batch 模式的实现核心链路如下tsc.batch-impl.ts 首先对任务图内的每个任务做选项归一化normalizeTasksOptions并统一处理clean若某任务设置了clean: true会先递归清空其输出目录接着为每个任务生成内存中的临时 tsconfiggetProcessedTaskTsConfigs将任务间的依赖关系以 TypeScript 项目引用的形式串联起来核心编译函数compileTypescriptSolutiontypescript-compilation.ts使用ts.createSolutionBuilder非 watch 模式或ts.createSolutionBuilderWithWatchwatch 模式构建解决方案通过getNextInvalidatedProject()逐个取出需要编译的项目由于整个解决方案在同一进程内共享TypeScript 的增量缓存.tsbuildinfo和程序缓存得以复用从而避免默认实现中每个任务独立起一个 tsc 进程、重复解析与类型检查的开销。3.4 性能优化clean: false与.tsbuildinfo文档给出了一条明确的性能优化建议为了发挥批量模式的增量优势可把clean选项设为false{ build: { executor: nx/js:tsc, options: { outputPath: dist/libs/ts-lib, main: libs/ts-lib/src/index.ts, tsConfig: libs/ts-lib/tsconfig.lib.json, assets: [libs/ts-lib/*.md], clean: false } } }原因在于clean默认值为true见 schema.json构建前会清空输出目录导致 TypeScript 生成的.tsbuildinfo增量缓存文件一并丢失增量构建的关键优化也随之失效。设置clean: false后tsc的增量构建机制可以跨构建复用编译状态大幅缩短重复构建耗时。需要强调的是文档明确指出这不是硬性要求——即使不关闭cleanbatch 实现依然有进程复用、程序共享等其他重要优化收益。此外从 tsc.batch-impl.ts 可以看到批处理还处理了任务被判定为受影响但实际 TS 项目无文件变更的边界场景如命中缓存或--skip-nx-cache此时会跳过 TypeScript 编译但继续完成资产复制与package.json更新确保任务结果完整上报。四、常用选项速查除transformers与clean外schema.json 还定义了以下常用选项供配置nx/js:tsc目标时参考选项类型默认值说明mainstring-主入口文件路径必填支持.js/.ts/.jsx/.tsxoutputPathstring-构建产物输出目录必填tsConfigstring-TypeScript 配置文件路径必填rootDirstring项目根目录指定编译的 rootDir不设置时使用项目根目录outputFileNamestring-主文件相对outputPath的输出文件名assetsarray[]静态资源列表支持字符串或{glob, input, output, ignore, includeIgnoredFiles}对象watchbooleanfalse文件变更时自动重新构建cleanbooleantrue构建前清空输出目录transformersarray[]TypeScript Transformer 插件列表generatePackageJsonbooleantrue是否在输出目录生成package.jsongenerateExportsFieldbooleanfalse是否更新输出package.json的exports字段generatePackageJsonfalse时忽略additionalEntryPointsarray-追加到exports字段的额外入口点同上受generatePackageJson约束generateLockfilebooleanfalse生成与工作区锁文件匹配的锁文件保证依赖版本一致includeIgnoredAssetFilesbooleanfalse复制资产时是否包含被.gitignore/.nxignore忽略的文件注意这些文件不参与任务哈希计算需要额外配置inputs才能被 Nx 缓存正确跟踪值得留意的是assets的对象形式当配置为对象时glob、input、output三项均为必填input默认指向项目根目录output为产物目录内的绝对路径schema.json。这与文档示例中assets: [libs/ts-lib/*.md]的字符串简写形式互为补充字符串适合从项目根目录按 glob 复制到输出根目录的常见场景对象形式则适合需要精确控制来源目录、忽略规则与输出位置的复杂场景。五、与 Watch 模式及模块格式的协同在 watch 模式下watch: true默认实现tsc.impl.ts要求 Nx Daemon 处于启用状态否则资产与package.json不会随文件变更自动更新构建时会给出警告。当 Daemon 启用时执行器会监听资产变更与项目package.json变更并在收到SIGINT/SIGTERM时优雅释放监听器。另一个容易被忽视的细节是模块格式判定determineModuleFormatFromTsConfigtsc.impl.ts会读取编译后的 tsconfig 选项来决定输出格式并写入生成的package.jsonmodule为NodeNext时还需结合项目package.json的type字段判断type: module输出 ESM否则为 CJSmodule为ES2015/ES2020/ES2022/ESNext时判定为 ESM其余情况判定为 CJS。这意味着在开启generatePackageJson的前提下Nx 会自动根据你的 tsconfig 与 package.json 推断产物格式你无需手写输出包的类型字段。在 batch 模式下同一套判定逻辑同样作用于每个任务tsc.batch-impl.ts保证批量构建产出的包信息与单任务构建完全一致。六、小结围绕 packages/js/docs/tsc-examples.md 这份示例文档本文完整还原了nx/js:tsc的两个进阶用法Transformer 插件通过transformers选项字符串或{name, options}对象挂载编译期转换插件底层由 load-ts-transformers.ts 统一加载并按before/after/afterDeclarations三个阶段注入兼容标准与函数式两种插件导出形态Batch 批量构建自 Nx 16.6.0 起可用--batch让多个nx/js:tsc任务在单进程内共享 TypeScript 增量构建能力任务图越大收益越明显配合clean: false保留.tsbuildinfo可进一步放大增量优化效果同时需满足依赖项目均可构建且同为 tsc 执行器的前置条件。对于 Nx 工作区中大量使用nx/js:tsc构建库的场景这两个特性组合起来既能让复杂元编程插件与常规编译无缝融合又能在多包构建时显著压缩整体耗时是值得投入的优化方向。【免费下载链接】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），仅供参考
