umi 自定义模板:2 条路径怎么选

umi 自定义模板:2 条路径怎么选【免费下载链接】umiA framework in react community ✨项目地址: https://gitcode.com/GitHub_Trending/um/umi敲下umi create admin,在列表里挑一个 Simple App,几秒后目标目录被文件填满,依赖装完,git 也初始化好了。这条链路全部由 umi 的 create-umi 包完成,逻辑集中在一个入口文件里:packages/create-umi/src/index.ts,打开能看到交互提问、两种模板来源、monorepo 探测、依赖安装各自独立成函数,是理解 umi 脚手架模板机制的起点。读懂 create-umi 的模板分支:内置目录与 --template 参数整个生成器在解析完命令行参数后,只经过一个开关:有没有传--template。两个分支的文件来源完全不同。没传时走内置模板:模板目录就放在 packages/create-umi/templates/,app、max、vue-app、plugin 四个目录,由 BaseGenerator 读取并写入目标目录;提问环节用的是 clackPrompts,四个选项对应这四个目录,插件模板还会多问一个包名。传了--template时进入外部模板路径,交给 packages/create-umi/src/template.ts 里的 unpackTemplate 处理。这个文件只做三件事:包名归一化、到 registry(npm 注册表服务)查询最新版本、下载 tar 包(npm 发布的压缩包产物)并解压。// 无论用户怎么写,包名都归一化成 umijs/xxx-template 形式 const isScoped rawName.startsWith(umijs/); const hasTplSuffix rawName.endsWith(-template); let candidate: string; if (hasTplSuffix) { candidate isScoped ? rawName : umijs/${rawName}; // 只缺 scope 就补 scope } else { candidate isScoped ? ${rawName}-template : umijs/${rawName}-template; // 只缺后缀就补后缀 }为什么用 npm registry 做模板分发为什么 umi 不自建一套模板服务?答案在模板是什么:它就是一堆文件,没有运行时依赖,分发所需的东西——版本号、镜像源、tarball 下载——npm 恰好一次给齐。代价是包名必须遵守约定:要么以 -template 结尾,要么挂在 umijs 命名空间下,这也顺便保证了模板名全局唯一。换个角度看,解压逻辑里有个容易漏掉的细节:unpack({ C: dest, strip: 1 })中的 strip 参数会剥掉 npm 包的根目录层,于是目标项目里直接是 src 和 package.json,而不是多套一层 package/。这正是编写外部模板的隐性约定——项目骨架必须放在 npm 包的根部。tpl 文件约定:Mustache 模板渲染的上下文来源内置模板路径里还有一条统一规则:任何以 .tpl 结尾(模板文件标记)的文件,落盘前都要经过 Mustache(一种按 mustache 语法做文本替换的模板引擎)渲染。实现见 packages/utils/src/BaseGenerator/BaseGenerator.ts,其中 writing() 分三种情况:.tpl 走渲染,普通文件原样拷贝,目录则递归处理;渲染用的上下文就是 index.ts 里拼好的那份数据——umi 版本、npm 客户端、本机 git 配置里的 author 和 email。// 生成器对 .tpl 文件的处理:读原文 → 渲染 → 落盘 const raw fs.readFileSync(tplPath, utf-8); const rendered Mustache.render(raw, ctx); // {{{ version }}} 在此被替换 fs.mkdirpSync(dirname(destPath)); fs.writeFileSync(destPath, rendered, utf-8);对照 templates 目录下 app 的 package.json.tpl,就能看到哪些字段被注入了:{ author: {{{ author }}}, // 取自本机 git 配置 dependencies: { umi: {{{ version }}} // 当前 umi 版本号 } }自建模板的 2 条路径:npm 包与自定义 CLI外部模板:发布成 npm 包。这是 umi 当前唯一支持的外部模板投递方式。把包命名为xxx-template,项目骨架放在包根部,发布到团队私有 registry,成员执行umi create app --template xxx-template即可拉取。由于 unpackTemplate 先查{registry}/xxx-template/latest,发布时要用正式版本,分支产物拉不到。内部风格:自建脚手架 CLI。不想受 npm 发布约束时,可以参照 examples/cli-custom/——它用 umi 的 run() 加一个 preset 搭出最小 CLI;在 examples/cli-custom/src/features/eat.ts 里能看到 registerCommand 与 zod 配置校验怎么配合,把它换成你团队的选功能提问,就是一份现成的蓝图。边界情况:monorepo 与 pnpm 的隐藏处理源码里有几个静默行为值得留意:目标目录若落在 monorepo(一个仓库装多个包,靠 lerna.json 或 pnpm-workspace.yaml 识别)内,.npmrc 会被挪到工作区根目录,husky 目录被移除;pnpm 8 会自动补跑pnpm up -L,绕开它装最低版本依赖的行为。另外源码留了一个 TODO:从 git 初始化模板——外部模板目前只支持 npm 分发,团队模板若存放在内部 git 仓库,得先自行 clone 再调用,或者干脆打成 npm 包发布。马上可以做的两件事:运行umi create --help摸清--template、--git、--install几个开关,再对照 index.ts 核对每个分支的触发条件;若团队确实需要统一脚手架,把第一个模板包命名为team-template,骨架放进包根部,发到私有 registry,用umi create app --template team-template生成第一个项目验证耗时。【免费下载链接】umiA framework in react community ✨项目地址: https://gitcode.com/GitHub_Trending/um/umi创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考