使用 Nx Plugin 的 create-package 生成器打造可发布的脚手架 CLI 包【免费下载链接】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/nxnx/plugin:create-package是 Nx Plugin 包提供的生成器它能在你的 Nx 工作区中快速创建一个可执行CLI包这个包以create-开头命名可发布到 npm用户通过npx运行它即可初始化一个全新的 Nx workspace并自动套用你插件内置的 preset。读完本文你将掌握该生成器的完整命令用法、全部配置参数、生成产物结构、底层实现原理以及从开发到发布使用的完整闭环。一条命令生成你的脚手架 CLI原文档给出的核心示例非常精炼假设你的 Nx 插件项目名为my-plugin想为它配套一个名为create-my-plugin的 CLI 包只需执行nx g nx/plugin:create-package create-my-plugin --project my-plugin该生成器在 generators.json 中注册描述为 Create a package which can be used by npx to create a new workspace即创建一个可被npx用于创建新 workspace 的包。执行后工作区中会新增一个库项目其package.json包含指向./bin/index.js的bin入口构建产物即为一个可全局执行或经npx调用的命令行工具。生成器全部参数详解该生成器的完整参数定义在 schema.json其中directory、name、project三个为必填项。以下是全部参数的说明参数类型必填说明directorystring✅放置新 CLI 包的目录位置参数默认取命令行第一个位置参数namestring✅CLI 的包名如create-framework-package必须匹配create-.\|^./create(?:-.)?模式且必须是可发布的有效 npm 名称projectstring✅插件生成器所在的项目名别名-p默认取当前项目名会弹出交互提示unitTestRunnerstring❌单元测试运行器取值none、jest、vitestlinterstring❌静态检查工具取值none、eslint、oxlint不指定时默认沿用工作区已有配置tagsstring❌添加到库的标签用于 lint 约束别名-tskipFormatboolean❌是否跳过文件格式化默认falsecompilerstring❌构建与测试目标使用的编译器取值tsc默认或swce2eProjectstring❌e2e 项目名称提供后会在该 e2e 项目中注入对 CLI 的端到端测试留空则跳过useProjectJsonboolean❌是否使用独立的project.json配置文件而非将 Nx 配置内联进package.json参数校验与规范化的底层逻辑生成器首先通过 normalize-schema.ts 对参数做规范化linter、unitTestRunner未指定时会通过normalizeLinterOption/normalizeUnitTestRunnerOption继承工作区既有约定unitTestRunner默认偏向jest若未提供directory会直接抛出错误提示Please provide the --directory option. It should be the directory containing the project ...可见该参数对确定新包落位至关重要compiler会被映射为内部使用的bundler字段tsc | swc会结合isUsingTsSolutionSetup与shouldConfigureTsSolutionSetup判断当前是否处于 TS solution 工程布局进而决定useProjectJson的默认值与bin产物路径TS solution 下为./dist/bin/index.js。生成器内部做了什么源码级拆解核心实现位于 create-package.ts整个流程可概括为五步1. 自动补全 preset 生成器。addPresetGenerator会检查插件项目是否已有preset生成器若没有则调用generatorGenerator自动创建一个名为preset的生成器并读取插件package.json的name作为后续 preset 标识。注意源码注释中的细节只有linter eslint时才执行 lint checks因为 Lint checks are an ESLint-only feature。2. 注入依赖。通过addDependenciesToPackageJson为新包加入create-nx-workspace版本与当前 Nx 对齐取自nxVersion若使用tsc编译器还会额外加入tslib依赖。3. 生成可发布的 JS 库骨架。调用nx/js的libraryGenerator以publishable: true、bundler: options.bundler、importPath: options.name的方式创建库随后删除默认的src目录将其改造为纯 CLI 包。4. 写入bin入口并调整构建目标。在package.json中写入bin: { [options.name]: ./bin/index.js }将项目的sourceRoot指向bin目录并把targets.build.options.main改为bin/index.ts同时将插件项目注册为implicitDependencies确保 CLI 包始终在插件之后构建。在 TS solution 布局下还会删除main、types、exports等字段——因为该包只暴露二进制入口不暴露 JS 编程 API。5. 生成模板文件并注入 e2e 测试。最后从files/create-framework-package模板目录生成bin/index.ts等文件若提供了e2eProject还会在 e2e 项目中生成针对该 CLI 的端到端测试。测试用例 create-package.spec.ts 验证了上述关键行为生成后project.root指向目标目录、sourceRoot为root/bin、构建目标使用nx/js:tsc且main为bin/index.ts、输出路径为dist/packages/create-a-workspace。生成的 CLI 入口长什么样模板文件 bin/index.ts__tmpl__ 是 CLI 包的核心其逻辑清晰直观#!/usr/bin/env node import { createWorkspace } from create-nx-workspace; async function main() { const name process.argv[2]; // 工作区名称可用 yargs/enquirer 等库增强交互 if (!name) { throw new Error(Please provide a name for the workspace); } console.log(Creating the workspace: ${name}); // 假设 preset 插件与 CLI 包处于同一版本 const presetVersion require(../package.json).version; // TODO: 按需定制工作区初始化参数 const { directory } await createWorkspace( preset${presetVersion}, { name, nxCloud: skip, packageManager: npm, } ); console.log(Successfully created the workspace: ${directory}.); } main();核心机制一目了然CLI 通过createWorkspace以{preset}{version}的形式调用 preset预设版本号取自 CLI 包自身的版本保证二者版本一致nxCloud、packageManager等选项均为模板中可进一步自定义的初始值。端到端验证模板与真实测试模板自带的 e2e 测试若指定了e2eProject生成器会在该 e2e 项目中生成cliName.spec.ts__tmpl__。这段测试的流程完整还原了 CLI 的真实使用场景在临时目录tmp/test-project下通过packageManager.dlx create-my-plugine2e test-project执行 CLI创建一个测试工作区在该工作区中执行npm ls pluginPackageName验证插件包已正确安装npm ls 在安装不正确时会失败测试结束afterAll后递归清理临时目录。测试用例特意设置了180_000毫秒的超时预算因为该测试同步地 shell 调用外部命令预算必须覆盖冷启动的包管理器缓存。真实 e2e 测试佐证仓库中对应 e2e 包 e2e/nx/ 与 e2e/plugin/ 对create-package生成器做了覆盖验证了从生成器执行到产物可用的完整链路。你可以将上述模板测试作为自己插件的出厂自检确保 CLI 在任何环境都能从零拉起一个 workspace。完整工作流从生成到发布再到使用1. 生成 CLI 包。在包含my-plugin插件项目的工作区中执行nx g nx/plugin:create-package create-my-plugin --project my-plugin2. 按需定制。修改生成的bin/index.ts例如调整packageManager、接入交互式提示库、支持额外命令行参数模板中留有 TODO 注释建议同步完善 preset 生成器src/generators/preset/generator.ts让新建的 workspace 自带你插件期望的默认结构与配置。3. 构建并本地验证。nx build create-my-plugin构建产物位于dist/packages/create-my-plugin含bin/index.js与完整package.json可先通过npm pack在本地安装试运行或直接运行 e2e 项目完成自动验证。4. 发布到 npm。以npm publish发布该 CLI 包name需符合create-.或 scopedscope/create-*的 npm 命名规范这也是 schema 中pattern的校验来源。5. 用户侧使用。任何开发者只需一条命令即可获得一个套用了你插件 preset 的全新 Nx workspacenpx create-my-plugin my-app其内部即调用createWorkspace(my-pluginversion, {...})这与官方 preset 的注册方式一致——在 generators.json 中preset生成器正是面向create-nx-workspace --preset nx/plugin这类调用场景设计的。实践要点与约束命名即规范name必须以create-开头或为scope/create-*这既是 npm 生态的惯例也是 schema 正则校验的硬性要求directory必不可少它决定了 CLI 包在工作区中的落位未提供时生成器会直接报错版本一致性假设生成的 CLI 假定插件 preset 与其处于同一版本presetVersion取自 CLI 自身package.json发布时需同步版本CLI 与插件解耦CLI 包仅暴露bin入口、不暴露编程 APITS solution 布局下main/types/exports会被删除保持轻量测试先行借助e2eProject参数让每次改动都有端到端兜底避免发布后才暴露初始化流程问题。至此你已拥有从一条生成器命令到一个可发布、可被 npx 消费的脚手架 CLI的完整能力这正是 Nx 插件生态中分发 preset、放大开发者与 AI Agent 生产力的标准姿势。【免费下载链接】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 Plugin 的 create-package 生成器打造可发布的脚手架 CLI 包
使用 Nx Plugin 的 create-package 生成器打造可发布的脚手架 CLI 包【免费下载链接】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/nxnx/plugin:create-package是 Nx Plugin 包提供的生成器它能在你的 Nx 工作区中快速创建一个可执行CLI包这个包以create-开头命名可发布到 npm用户通过npx运行它即可初始化一个全新的 Nx workspace并自动套用你插件内置的 preset。读完本文你将掌握该生成器的完整命令用法、全部配置参数、生成产物结构、底层实现原理以及从开发到发布使用的完整闭环。一条命令生成你的脚手架 CLI原文档给出的核心示例非常精炼假设你的 Nx 插件项目名为my-plugin想为它配套一个名为create-my-plugin的 CLI 包只需执行nx g nx/plugin:create-package create-my-plugin --project my-plugin该生成器在 generators.json 中注册描述为 Create a package which can be used by npx to create a new workspace即创建一个可被npx用于创建新 workspace 的包。执行后工作区中会新增一个库项目其package.json包含指向./bin/index.js的bin入口构建产物即为一个可全局执行或经npx调用的命令行工具。生成器全部参数详解该生成器的完整参数定义在 schema.json其中directory、name、project三个为必填项。以下是全部参数的说明参数类型必填说明directorystring✅放置新 CLI 包的目录位置参数默认取命令行第一个位置参数namestring✅CLI 的包名如create-framework-package必须匹配create-.\|^./create(?:-.)?模式且必须是可发布的有效 npm 名称projectstring✅插件生成器所在的项目名别名-p默认取当前项目名会弹出交互提示unitTestRunnerstring❌单元测试运行器取值none、jest、vitestlinterstring❌静态检查工具取值none、eslint、oxlint不指定时默认沿用工作区已有配置tagsstring❌添加到库的标签用于 lint 约束别名-tskipFormatboolean❌是否跳过文件格式化默认falsecompilerstring❌构建与测试目标使用的编译器取值tsc默认或swce2eProjectstring❌e2e 项目名称提供后会在该 e2e 项目中注入对 CLI 的端到端测试留空则跳过useProjectJsonboolean❌是否使用独立的project.json配置文件而非将 Nx 配置内联进package.json参数校验与规范化的底层逻辑生成器首先通过 normalize-schema.ts 对参数做规范化linter、unitTestRunner未指定时会通过normalizeLinterOption/normalizeUnitTestRunnerOption继承工作区既有约定unitTestRunner默认偏向jest若未提供directory会直接抛出错误提示Please provide the --directory option. It should be the directory containing the project ...可见该参数对确定新包落位至关重要compiler会被映射为内部使用的bundler字段tsc | swc会结合isUsingTsSolutionSetup与shouldConfigureTsSolutionSetup判断当前是否处于 TS solution 工程布局进而决定useProjectJson的默认值与bin产物路径TS solution 下为./dist/bin/index.js。生成器内部做了什么源码级拆解核心实现位于 create-package.ts整个流程可概括为五步1. 自动补全 preset 生成器。addPresetGenerator会检查插件项目是否已有preset生成器若没有则调用generatorGenerator自动创建一个名为preset的生成器并读取插件package.json的name作为后续 preset 标识。注意源码注释中的细节只有linter eslint时才执行 lint checks因为 Lint checks are an ESLint-only feature。2. 注入依赖。通过addDependenciesToPackageJson为新包加入create-nx-workspace版本与当前 Nx 对齐取自nxVersion若使用tsc编译器还会额外加入tslib依赖。3. 生成可发布的 JS 库骨架。调用nx/js的libraryGenerator以publishable: true、bundler: options.bundler、importPath: options.name的方式创建库随后删除默认的src目录将其改造为纯 CLI 包。4. 写入bin入口并调整构建目标。在package.json中写入bin: { [options.name]: ./bin/index.js }将项目的sourceRoot指向bin目录并把targets.build.options.main改为bin/index.ts同时将插件项目注册为implicitDependencies确保 CLI 包始终在插件之后构建。在 TS solution 布局下还会删除main、types、exports等字段——因为该包只暴露二进制入口不暴露 JS 编程 API。5. 生成模板文件并注入 e2e 测试。最后从files/create-framework-package模板目录生成bin/index.ts等文件若提供了e2eProject还会在 e2e 项目中生成针对该 CLI 的端到端测试。测试用例 create-package.spec.ts 验证了上述关键行为生成后project.root指向目标目录、sourceRoot为root/bin、构建目标使用nx/js:tsc且main为bin/index.ts、输出路径为dist/packages/create-a-workspace。生成的 CLI 入口长什么样模板文件 bin/index.ts__tmpl__ 是 CLI 包的核心其逻辑清晰直观#!/usr/bin/env node import { createWorkspace } from create-nx-workspace; async function main() { const name process.argv[2]; // 工作区名称可用 yargs/enquirer 等库增强交互 if (!name) { throw new Error(Please provide a name for the workspace); } console.log(Creating the workspace: ${name}); // 假设 preset 插件与 CLI 包处于同一版本 const presetVersion require(../package.json).version; // TODO: 按需定制工作区初始化参数 const { directory } await createWorkspace( preset${presetVersion}, { name, nxCloud: skip, packageManager: npm, } ); console.log(Successfully created the workspace: ${directory}.); } main();核心机制一目了然CLI 通过createWorkspace以{preset}{version}的形式调用 preset预设版本号取自 CLI 包自身的版本保证二者版本一致nxCloud、packageManager等选项均为模板中可进一步自定义的初始值。端到端验证模板与真实测试模板自带的 e2e 测试若指定了e2eProject生成器会在该 e2e 项目中生成cliName.spec.ts__tmpl__。这段测试的流程完整还原了 CLI 的真实使用场景在临时目录tmp/test-project下通过packageManager.dlx create-my-plugine2e test-project执行 CLI创建一个测试工作区在该工作区中执行npm ls pluginPackageName验证插件包已正确安装npm ls 在安装不正确时会失败测试结束afterAll后递归清理临时目录。测试用例特意设置了180_000毫秒的超时预算因为该测试同步地 shell 调用外部命令预算必须覆盖冷启动的包管理器缓存。真实 e2e 测试佐证仓库中对应 e2e 包 e2e/nx/ 与 e2e/plugin/ 对create-package生成器做了覆盖验证了从生成器执行到产物可用的完整链路。你可以将上述模板测试作为自己插件的出厂自检确保 CLI 在任何环境都能从零拉起一个 workspace。完整工作流从生成到发布再到使用1. 生成 CLI 包。在包含my-plugin插件项目的工作区中执行nx g nx/plugin:create-package create-my-plugin --project my-plugin2. 按需定制。修改生成的bin/index.ts例如调整packageManager、接入交互式提示库、支持额外命令行参数模板中留有 TODO 注释建议同步完善 preset 生成器src/generators/preset/generator.ts让新建的 workspace 自带你插件期望的默认结构与配置。3. 构建并本地验证。nx build create-my-plugin构建产物位于dist/packages/create-my-plugin含bin/index.js与完整package.json可先通过npm pack在本地安装试运行或直接运行 e2e 项目完成自动验证。4. 发布到 npm。以npm publish发布该 CLI 包name需符合create-.或 scopedscope/create-*的 npm 命名规范这也是 schema 中pattern的校验来源。5. 用户侧使用。任何开发者只需一条命令即可获得一个套用了你插件 preset 的全新 Nx workspacenpx create-my-plugin my-app其内部即调用createWorkspace(my-pluginversion, {...})这与官方 preset 的注册方式一致——在 generators.json 中preset生成器正是面向create-nx-workspace --preset nx/plugin这类调用场景设计的。实践要点与约束命名即规范name必须以create-开头或为scope/create-*这既是 npm 生态的惯例也是 schema 正则校验的硬性要求directory必不可少它决定了 CLI 包在工作区中的落位未提供时生成器会直接报错版本一致性假设生成的 CLI 假定插件 preset 与其处于同一版本presetVersion取自 CLI 自身package.json发布时需同步版本CLI 与插件解耦CLI 包仅暴露bin入口、不暴露编程 APITS solution 布局下main/types/exports会被删除保持轻量测试先行借助e2eProject参数让每次改动都有端到端兜底避免发布后才暴露初始化流程问题。至此你已拥有从一条生成器命令到一个可发布、可被 npx 消费的脚手架 CLI的完整能力这正是 Nx 插件生态中分发 preset、放大开发者与 AI Agent 生产力的标准姿势。【免费下载链接】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），仅供参考