用途
nx-generate 是一个围绕 Nx 生成器（generator）的技能，用于在 Nx monorepo 中自动生成代码。Nx 生成器可以搭建项目、执行自动化代码迁移，或自动化重复性任务，帮助保持代码库一致性并减少样板工作。
该技能适用于用户想要：
- 创建新项目，例如库（library）或应用（application）
- 搭建功能模块或样板代码
- 运行工作区专属或自定义生成器
- 完成任何已有对应 Nx 生成器的任务
主要能力与关键原则
- 始终使用
--no-interactive，避免交互式提示导致执行挂起。 - 阅读生成器源码：仅看 schema 不够，需要理解生成器实际做了什么。
- 匹配仓库既有模式：研究仓库中类似产物并遵循其约定。
- 使用 lint/test/build/typecheck 等进行验证：生成的代码必须通过验证，所列目标仅为示例，应使用适合当前工作区的目标。
使用方式
1. 发现可用生成器
使用 Nx CLI 发现可用生成器：
- 列出某个插件的所有生成器：
npx nx list @nx/react - 查看可用插件：
npx nx list
这包括插件生成器（例如 @nx/react:library）和本地工作区生成器。
2. 将生成器与用户请求匹配
识别哪些生成器可以满足用户需求，考虑用户想要的产物类型、相关框架，以及提到的具体生成器名称。
重要：当本地工作区生成器和外部插件生成器都能满足请求时，始终优先使用本地工作区生成器，因为本地生成器针对特定仓库的模式进行了定制。
如果没有合适的生成器，可以停止使用该技能。但举证责任很高——在决定没有适用生成器之前，应仔细考虑所有可用生成器。
3. 获取生成器选项
使用 --help 标志了解可用选项：
npx nx g @nx/react:library --help
注意必填选项、可能需要覆盖的默认值，以及与用户请求相关的选项。
库的可构建性
除非有特定理由需要可构建，否则默认使用不可构建（non-buildable）库。
| 类型 | 何时使用 | 生成器标志 |
|---|---|---|
| 不可构建（默认） | 由应用消费的内部 monorepo 库 | 无 --bundler 标志 |
| 可构建 | 发布到 npm、跨仓库共享、用于缓存命中的稳定库 | --bundler=vite 或 --bundler=swc |
不可构建库：
- 直接导出
.ts/.tsx源码 - 由消费方的打包器编译
- 开发体验更快，配置更少
可构建库：
- 拥有自己的 build 目标
- 适用于很少变化的稳定库（缓存命中）
- 发布到 npm 所必需
如果不清楚，询问用户：“这个库应该是可构建的（有自己的构建步骤，更好的缓存）还是不可构建的（直接消费源码，设置更简单）？”
4. 阅读生成器源码
这一步至关重要。仅凭 schema 无法了解全部信息。阅读源码有助于：
- 确切了解将创建/修改哪些文件以及位置
- 理解副作用（更新配置、安装依赖等）
- 识别 schema 中不明显的行文和选项
- 理解选项之间如何交互
查找生成器源码：
- 对于插件生成器：使用
node -e "console.log(require.resolve('@nx/<plugin>/generators.json'));"找到 generators.json，然后从那里定位源码 - 如果失败，直接从
node_modules/<plugin>/generators.json读取 - 对于本地生成器：通常在
tools/generators/或本地插件目录中。在仓库中搜索生成器名称。
阅读源码后重新考虑：这是正确的生成器吗？如果不是，回到第 2 步。
⚠️ --directory 标志的行为可能具有误导性。它应指定生成的库或组件的完整路径，而不是将要生成到的父路径。
# ✅ 正确 - directory 是库的完整路径
nx g @nx/react:library --directory=libs/my-lib
# 生成 libs/my-lib/package.json 等
# ❌ 错误 - 这会在 libs 和 libs/src/... 创建文件
nx g @nx/react:library --name=my-lib --directory=libs
# 生成 libs/package.json 等
5. 检查既有模式
生成之前，检查代码库的目标区域：
- 查看类似的既有产物（其他库、应用等）
- 识别命名约定、文件结构和配置模式
- 注意使用了哪些测试运行器、构建工具和 linter
- 配置生成器以匹配这些模式
6. Dry-Run 验证文件位置
始终先使用 --dry-run 运行，验证文件将创建在正确位置：
npx nx g @nx/react:library --name=my-lib --dry-run --no-interactive
仔细检查输出。如果文件将创建在错误位置，根据从生成器源码中学到的内容调整选项。
注意：某些生成器不支持 dry-run（例如安装 npm 包时）。如果 dry-run 因此失败，继续实际运行生成器。
7. 运行生成器
执行生成器：
nx generate <generator-name> <options> --no-interactive
提示：新包通常需要连接工作区依赖（例如导入共享类型、被应用消费）。link-workspace-packages 技能可以帮助正确添加这些依赖。
8. 修改生成的代码（如需要）
生成器提供起点。根据需要修改输出以：
- 按请求添加或修改功能
- 调整导入、导出或配置
- 与既有代码模式集成
重要：如果替换或删除生成的测试文件（例如 *.spec.ts），要么编写有意义的替代测试，要么从项目配置中移除测试目标。空测试套件会导致 nx test 失败。
9. 格式化与验证
格式化所有生成/修改的文件：
nx format --fix
此示例适用于使用 prettier 的内置 nx 格式化。工作区可能有其他格式化工具，适当时使用这些工具。
然后验证生成的代码可以工作。请记住，通过生成器或后续修改所做的更改可能影响多个项目，因此通常仅对刚创建的产物运行目标是不够的。
# 这些目标只是示例！
nx run-many -t build,lint,test,typecheck
这些目标是许多工作区中常见的示例。你应该研究当前工作区及其项目可用的其他目标。CI 配置通常是了解必须通过的关键目标的好指南。
如果验证失败但问题可控（少量 lint 错误、轻微类型问题），修复它们。如果问题广泛，先尝试明显的修复，然后向用户升级，说明生成了什么、什么失败了以及你尝试了什么。
适用场景
- 在 Nx monorepo 中创建新的库或应用
- 搭建功能模块或样板代码
- 运行工作区专属或自定义生成器
- 需要自动化重复性任务或代码迁移
限制
- 仅适用于 Nx monorepo 环境。
- 某些生成器不支持 dry-run（例如安装 npm 包时）。
- 若替换或删除生成的测试文件，需编写替代测试或移除测试目标，否则
nx test会失败。 - 验证目标因工作区而异，需根据实际工作区和 CI 配置确定。