Create Web Kit

基于官方脚手架命令的前端项目 setup flow CLI。

它要解决的不是“如何再造一个模板仓库”，而是另一个更常见的问题： 我们用官方脚手架把项目创建出来以后，通常还要继续手动补一串几乎重复的工程化步骤，比如装 UI、补 ESLint / Prettier、接 Husky / lint-staged、整理环境变量、放入公共请求封装、补默认目录和配置文件。这些事情本质上往往就是一条条官方命令加少量配置改动，但每次新开项目都要再做一遍。

Create Web Kit 的核心就是把这类高频、重复、可标准化的初始化动作整理成一条可复用的 flow，让常见类型的仓库可以通过一条命令直接落地到“能开始认真开发”的状态。

核心原理

Create Web Kit 默认不维护一整套庞大的自定义模板，而是围绕下面这个模型工作：

1. 先调用官方脚手架 比如 create-next-app、create-vue、create-monkey、electron-vite。
2. 再执行该方案对应的增强步骤 比如安装 UI 库、数据层、工程化依赖，或者执行额外的初始化命令。
3. 最后补少量增量文件和配置 比如 .env、eslint、prettier、husky、默认 providers、请求封装、脚本约定等。
4. 全程适配用户当前包管理器 自动根据环境尽量使用匹配的包管理器命令。

可以把它理解为：

官方 create 命令
+ 常用依赖安装
+ 常见工程化配置
+ 少量增量模板文件
= 一条可复用的项目搭建 flow

这个仓库的价值，不是替代官方，而是把“官方脚手架之后的重复劳动”产品化。

为什么不用纯模板

纯模板当然也能解决问题，但它的维护成本通常更高：

• 模板容易和官方最新结构脱节
• 框架升级时，模板要跟着整体迁移
• 很多改动其实只是“追加几条命令 + 覆盖几个配置文件”，没必要维护完整项目骨架

Create Web Kit 更偏向下面这套思路：

• 让官方脚手架继续作为项目初始结构的 source of truth
• 只维护团队真正高频复用的增强步骤
• 只复制必要的增量文件，而不是复制整个项目
• 把“个人经验”沉淀成可执行的 setup flow

它适合的场景

• 你经常创建相似类型的新仓库
• 你已经有一套自己反复验证过的工程化默认项
• 你希望尽量贴近官方最新脚手架，但不想每次都手动补配置
• 你想把个人或团队的建仓习惯收敛成统一命令

当前支持的 Flow

| Variant | 基于官方命令 | 典型增强内容 | | --- | --- | --- | | astro-content | create-astro | 内容站/官网默认首页、content collection、MDX/sitemap 起点、Prettier、环境变量示例 | | react-vite | create-vite | React SPA、shadcn/ui、TanStack Query/Table、Prettier、Husky、lint-staged、请求封装、Vite 环境变量示例 | | nextjs-csr | create-next-app | Shadcn UI、TanStack Query/Table、Prettier、Husky、lint-staged、环境变量、providers、请求封装、构建信息组件等 | | nextjs-ssr | create-next-app | Shadcn UI、React Query、NextAuth、Prisma、SSR 环境变量示例 | | vue3 | create-vue | Pinia、@vueuse/core、开发依赖、Vite 配置补充 | | nuxt3 | create-nuxt | Nuxt UI、Pinia、VueUse、runtime config、基础 API route、Prettier | | electron-react | create electron-vite | React + TypeScript 初始化、常用状态/请求依赖、ESLint 配置补充 | | electron-vue | create electron-vite | Vue 3 + TypeScript 初始化、Pinia、@vueuse/core、ESLint 配置补充 | | browser-extension-react | wxt init | Browser Extension React 默认入口名、Manifest V3、popup/options/content/background、Prettier、Husky | | wxt-react | wxt init | Browser Extension Manifest V3、popup/options/content/background 入口、Prettier、Husky、lint-staged | | astro-blog | create-astro | 官方 Blog 内容结构、MDX/SEO/RSS/sitemap 起点、Prettier、环境变量示例 | | userscript | create-monkey | Vanilla TypeScript userscript、@types/tampermonkey、Makefile、Vite 默认文件清理、userscript 约定文件 |

其中最重要的不是“支持了哪些框架”，而是每个 variant 都代表一条已经整理好的搭建 flow。

使用方法

交互式创建

npx create-web-kit

指定项目目录

npx create-web-kit my-project

直接指定方案

npx create-web-kit my-project --template nextjs-csr
npx create-web-kit my-project --template react-vite
npx create-web-kit my-project --template nuxt3
npx create-web-kit my-project --template browser-extension-react
npx create-web-kit my-project --template wxt-react
npx create-web-kit my-project --template astro-content
npx create-web-kit my-project --template astro-blog

非交互模式

npx create-web-kit my-project --template vue3 --yes

指定包管理器

npx create-web-kit my-project --template nextjs-csr --package-manager pnpm

跳过附加安装

npx create-web-kit my-project --template userscript --yes --no-install

跳过 Git 相关设置

npx create-web-kit my-project --template nextjs-csr --yes --no-git

查看帮助

npx create-web-kit --help

常见示例

npx create-web-kit admin-panel --template nextjs-csr
npx create-web-kit ops-console --template react-vite
npx create-web-kit content-site --template nextjs-ssr
npx create-web-kit company-site --template astro-content
npx create-web-kit creator-site --template astro-blog
npx create-web-kit member-portal --template nuxt3
npx create-web-kit browser-assistant --template browser-extension-react
npx create-web-kit browser-sidekick --template wxt-react
npx create-web-kit chrome-helper --template userscript
npx create-web-kit landing-page --template vue3 --yes

常用参数：

• --yes：使用默认值并跳过本 CLI 的交互问题
• --package-manager <npm|pnpm|yarn|bun>：强制使用指定包管理器
• --no-install：跳过附加依赖安装步骤
• --no-git：跳过 Git 相关增强步骤
• --verbose：输出更多执行细节
• --overwrite：目标目录非空时直接清空继续

一个 Variant 实际会做什么

以 nextjs-csr 为例，它并不是直接拷贝一个完整项目，而是大致执行下面这类动作：

create-next-app ...
pnpm dlx shadcn@latest init -y
pnpm add @tanstack/react-table @tanstack/react-query ...
pnpm add -D prettier husky lint-staged ...
复制和补充少量项目文件
更新 package.json 中的脚本和 lint-staged 配置

这正是整个仓库的核心思路：把本来散落在笔记、命令历史和个人习惯里的动作，收敛成可重复执行的工程初始化流程。

开发

项目结构

src/
├── index.ts           # CLI 入口与交互流程
├── cli/               # CLI 参数与交互辅助逻辑
├── config/            # 常量与帮助信息
├── registry/          # 模板/variant 注册表
├── variants/          # 结构化 variant 定义
├── core/              # flow 运行器、命令执行、文件操作、包管理器适配
├── generators/        # 每个 variant 的增量文件与 augment 逻辑
├── templates/         # 被复制到目标项目的模板碎片
├── assets/            # 静态资源
├── utils/             # 通用工具函数
└── types/             # 类型定义

本地开发

pnpm install
make dev
make build
pnpm start

测试与验证

pnpm run lint
pnpm run check

当你修改某个 variant、generator 或模板文件时，除了跑测试，最好再实际执行一次 CLI，确认生成出来的项目结构和脚本都符合预期。

发布与版本管理

make deploy

这个仓库的发布入口现在只保留一个：make deploy。

它会按下面的顺序执行：

1. 先把当前工作区改动提交成一次普通 commit
2. 交互式生成 changeset
3. 执行 changeset version，消费 changeset 并更新 package.json、CHANGELOG.md
4. 执行 pnpm run check
5. 提交 release 改动，然后执行 git push 和 npm publish

如果你想自定义 commit message，可以在执行时传环境变量：

make deploy MSG="feat: improve generator flow" RELEASE_MSG="release v26.408.1"

如何扩展新的搭建 Flow

1. 在 src/variants/ 中新增一个结构化 variant definition
2. 在 src/variants/index.ts 中导出并注册该 variant
3. 在 src/generators/ 和 src/templates/ 中补充增量文件与 augment 逻辑
4. 补对应的 tests/unit 或 tests/integration
5. 更新 README 和发布说明

新增能力时，优先思考的不是“我要不要再做一个模板”，而是： 这是不是一个可以复用的 setup flow。

License

MIT