[Task] 微应用脚手架 cli

[kuitos]

提供脚手架 cli 一键创建主应用 & 子应用，支持 React、vue 模板

[hakushinring]

报名此任务，有cli开发经验，通读过qiankun2.0代码，最早开始时间10.02，可长期维护

[kuitos]

太棒了！任务去这个帖子里回复领取哦🤝

[qiYuei]

能一起参与这个任务吗？

[kuitos]

你可以跟 @hakushinring 商量一下分个工哈哈

[qiYuei]

@hakushinring 咋样老哥，要不弄个联系方式商量下？ 也有开发cli经验

[hakushinring]

RFC create-qiankun

背景

为快速创建基于qiankun3.0的微前端项目开发的cli项目，帮助开发者快速上手微前端，解决并演示常见微前端项目面临问题

说明

防止模板被墙，模板存放在create-qiankun仓库中，随cli版本发布更新

模板选择

主应用

webpack

react18
vue3
umi
react18

子应用

webpack

react18
vue2 (基于vue-cli)
vue3 (基于vue-cli)

vite

react18 (基于vite-cli)
vue2 (基于vite-cli)
vue3 (基于vite-cli)

umi

react18

支持语言

javascript

仓库模式

pnpm monorepo

工程创建后的目录结构

my-project

packages

main-app //主应用
app1 // 子应用
app2
package.json

使用方式

npx create-qiankun my-project
cd my-project

开发
pnpm start

打包
pnpm build [package_name]

新增子应用
pnpm create:sub <app_name>

参数
create-qiankun <project_name>

实现策略

根据用户输入，下载对应模板，动态生成应用，项目默认自带一个主应用，一个子应用

• package.json 添加使用者username，email，package_name
• 子应用package.json添加属性qiankun

pnpm start

• 动态查询packages内，存在package.json且存在qiankun的文件夹；列出应用列表共用户多选，选择后启动应用

pnpm build <package_name>

• 此命令执行后当前项目根目录生成build/package_name文件夹

pnpm create:sub <app_name>

• 创建子应用，自动分配端口号

[SoldierAb]

RFC create-qiankun

背景

为快速创建基于qiankun3.0的微前端项目开发的cli项目，帮助开发者快速上手微前端，解决并演示常见微前端项目面临问题

说明

防止模板被墙，模板存放在create-qiankun仓库中，随cli版本发布更新

模板选择

主应用

webpack

react18
vue3
umi
react18

子应用

webpack

react18
vue2 (基于vue-cli)
vue3 (基于vue-cli)

vite

react18 (基于vite-cli)
vue2 (基于vite-cli)
vue3 (基于vite-cli)

umi

react18

支持语言

javascript

仓库模式

pnpm monorepo

工程创建后的目录结构

my-project

packages

main-app //主应用
app1 // 子应用
app2
package.json

使用方式

npx create-qiankun my-project cd my-project

开发 pnpm start

打包 pnpm build [package_name]

新增子应用 pnpm create:sub <app_name>

参数 create-qiankun <project_name>

实现策略

根据用户输入，下载对应模板，动态生成应用，项目默认自带一个主应用，一个子应用

• package.json 添加使用者username，email，package_name
• 子应用package.json添加属性qiankun

pnpm start

• 动态查询packages内，存在package.json且存在qiankun的文件夹；列出应用列表共用户多选，选择后启动应用

pnpm build <package_name>

• 此命令执行后当前项目根目录生成build/package_name文件夹

pnpm create:sub <app_name>

• 创建子应用，自动分配端口号

有没有可能引入插件设计？拆分模板，会更灵活一些。

[hakushinring]

RFC create-qiankun

背景

为快速创建基于qiankun3.0的微前端项目开发的cli项目，帮助开发者快速上手微前端，解决并演示常见微前端项目面临问题

说明

防止模板被墙，模板存放在create-qiankun仓库中，随cli版本发布更新

模板选择

主应用

webpack

react18
vue3
umi
react18

子应用

webpack

react18
vue2 (基于vue-cli)
vue3 (基于vue-cli)

vite

react18 (基于vite-cli)
vue2 (基于vite-cli)
vue3 (基于vite-cli)

umi

react18

支持语言

javascript

仓库模式

pnpm monorepo

工程创建后的目录结构

my-project

packages

main-app //主应用
app1 // 子应用
app2
package.json

使用方式

npx create-qiankun my-project cd my-project
开发 pnpm start
打包 pnpm build [package_name]
新增子应用 pnpm create:sub <app_name>
参数 create-qiankun <project_name>

实现策略

根据用户输入，下载对应模板，动态生成应用，项目默认自带一个主应用，一个子应用

• package.json 添加使用者username，email，package_name
• 子应用package.json添加属性qiankun

pnpm start

• 动态查询packages内，存在package.json且存在qiankun的文件夹；列出应用列表共用户多选，选择后启动应用

pnpm build <package_name>

• 此命令执行后当前项目根目录生成build/package_name文件夹

pnpm create:sub <app_name>

• 创建子应用，自动分配端口号

有没有可能引入插件设计？拆分模板，会更灵活一些。

那样会导致复杂度变高，目前用不上

[qiYuei]

命令基本都是基于 pnpm 如果用户没有装 pnpm 咋整😨

[hakushinring]

命令基本都是基于 pnpm 如果用户没有装 pnpm 咋整😨

monorepo 还是用pnpm好一些，能大量节省时间和空间，如果反对的人比较多可以考虑换到lerna

[kuitos]

通过 cli 创建出来的主子应用是monorepo可能不妥，我接触到的大部分微前端研发都是单仓模式

[hakushinring]

通过 cli 创建出来的主子应用是monorepo可能不妥，我接触到的大部分微前端研发都是单仓模式

在cli层面处理单仓库很麻烦，cli创建的主子应用如何关联起来？

[kuitos]

在cli层面处理单仓库很麻烦，cli创建的主子应用如何关联起来？

关联的交互应该是填 remote entry 的地址吧？需要填仓库地址吗？

[hakushinring]

填地址的方案不友好，很多项目在内网不一定有git地址，本机测试环境的项目也没有remote地址，我和 @qiYuei 讨论后，默认创建monorepo项目，单独创建主应用和子应用的时候不做任何管理，由用户自己处理（会在redeme上写明操作方式）

[kuitos]

不是 git 地址，指 localhost:3000 这种访问地址。
单独创建主应用和子应用的命令大概长什么样？monorepo 上手成本有点高，我担心提供这个方式后单纯 monorepo 的答疑就会不少

[qiYuei]

@kuitos 有几个问题需要确认下

1. cli 创建应用的时候限制主应用只能创建1个,子应用是否可以创建多个？
2. qiankun 配置规则 name和 activeRoute 读取应用模板中package.json的 name 是否可以？

//  package.json name = 'vue3'
{
   name: "vue3",
   entry: "//localhost:(端口)",
   container: "#subapp-container",
   activeRule: "/vue3",
 },

3. 创建应用的时候应用端口号是写死还是随机一个或者自增比如(9001开始)

[kuitos]

1. 是指的敲一次 cli 的流程里创建多个子应用么？这种诉求强烈吗，不强烈的话可以先不加，不用增加额外的复杂度
2. 可以的
3. 应该是冲突检测然后自增

[qiYuei]

1. 是指的敲一次 cli 的流程里创建多个子应用么？这种诉求强烈吗，不强烈的话可以先不加，不用增加额外的复杂度
2. 可以的
3. 应该是冲突检测然后自增

1. 是的 npx create-qiankun 执行命令选择模板，因为可以支持主子一起创建，所以我感觉创建多个不同框架的应用来测试好像也挺合理的
2. cli 层面应该检测不了端口冲突吧，有这个端口的应用在但是我没有跑。

[kuitos]

1. 那可以一起支持了
2. 哦你说创建时生成的模板里的端口么？那是不用检测，按自增生成就像。但是应用本身启动的命令里需要支持冲突检测

[qiYuei]

1. 那可以一起支持了
2. 哦你说创建时生成的模板里的端口么？那是不用检测，按自增生成就像。但是应用本身启动的命令里需要支持冲突检测

对说的是创建时的模板端口，自增的话也有一个问题。比如写死从8888开始自增第一次运行 npx create-qiankun 是从 8888 开始,第二次运行(npx 会重新下载)也是从 8888开始,冲突的概率就很大。我想的还是写个随机函数例如

// 特定的常用端口和系统端口
const commonPorts = [21, 22, 23, 25, 53, 80, 110, 443, 3306, 8080];

export function generatePort(excludes: number[] = []) {
  
  let port;
  do {
    // 随机生成一个端口号（1 - 65535）
    port = Math.floor(Math.random() * 65535) + 1;
  } while (commonPorts.includes(port) || port <= 1024 || excludes.includes(port));

  return port;
}

现有Vuecli、create-react-app等等都有配置端口 A 占用的话，会吧这个端口 A+1 这样的操作。 但是注册在 主应用的 配置信息已经写死 A ,而子应用此时真正运行的端口是 A+1 。这种情况要怎么处理，还是不用理 ？

[kuitos]

那不用考虑这种情况吧，反正启动时都还是会做冲突检测。配置没更新感觉很难解决，子应用启动后发现冲突了做一下提示吧，提示要更新主应用配置

[hakushinring]

自增可以根据主应用端口自增，比如主应用分配到9000，子应用就从9001开始

[hakushinring]

端口自增要考虑其他软件占用情况，我推荐是9000开始，冲突概率小一点

[qiYuei]

自增可以根据主应用端口自增，比如主应用分配到9000，子应用就从9001开始

怎么找到主应用位置并且找到端口，这是个难题。还是会有 多次执行npx create-qiankun 端口从 固定数开始导致冲突的