建议提供统一的工具链

[OxPatient]

hel的核心能力体验了下，非常nice。个人觉得会是一条微前端发展的路径

有几点个人期望，供大佬参考：

1. 源码monorepo管理模式；
2. 工具化，封装统一CLI；
3. CI、CD工具链，cdn，部署方案等；
4. IDE智能提示，远程dts加载等；
5. 代码、样式的隔离，装载，卸载等；

[OxPatient]

另外，项目后期还会开源吗，如何参与贡献？

[fantasticsoul]

fork项目提pr就好了，会一直持续开源。

1 源码pnpm monorepo 化已在计划中，预计国庆会改造完成 2 cli 这个欢迎贡献哈，目前精力有限 3 目前有用户打通了自己部署 npm 和 unpkg 并结合 hel-micro 做微模块加载的模式，后面他会掘金分享思路，这一块可以沉淀出来供用户复用 4 IDE提示是有的，按照我们的教材把源码发布到npm即可 5 样式隔离这些需要交给上层的ui框架适配层去做，hel-micro只提供远程模块加载功能（获取到模块的js对象，css描述文件等信息），例如hel-micro-react，完成了你说的这个功能，见示例：https://codesandbox.io/s/demo-load-remote-react-comp-2bnpl0

其他的例如 hel-micro-vue 欢迎贡献哈

[OxPatient]

感谢回复！

我尝试使用pnpm workspace + turbo进行改造，还没成功，卡在hel-dev-utils的build。 构建时缺少jsdom，添加依赖jsdom:^20.0.0后，构建报错：

[fantasticsoul]

如果改造成功欢迎提pr合到master呀，jsdom可以不提升到顶层么，独立成为 hel-dev-utils自己的依赖能解决这个问题么

[fantasticsoul]

加油，感觉你离成功不远了，多Google试试

[OxPatient]

加油，感觉你离成功不远了，多Google试试

build目前已经搞定，但start还有问题，启动路径不太正确

[fantasticsoul]

start 指的是 templates 下的 npm run start 吗，这个目录我还在思考要不要保留，后面的各种新示例会放到这里了 https://github.com/hel-eco

不过也期望你搞定 start 问题，这样 templates 保留几个最基础的模板用户测试修改也方便

[OxPatient]

start 指的是 templates 下的 npm run start 吗，这个目录我还在思考要不要保留，后面的各种新示例会放到这里了 https://github.com/hel-eco

不过也期望你搞定 start 问题，这样 templates 保留几个最基础的模板用户测试修改也方便

项目跑起来了， 想了解下，hel-pack有考虑开源吗？ 我个人更关注基于cdn的远程自动引入，而不是npm

[fantasticsoul]

hel-pack有考虑开源，不过因为它内部和蓝鲸devops打通了，需要花些时间剥离业务特性代码

开源出来的hel-pack其实还是不能直接使用，需要用户主动对接两个东西：1 上传构建产物到cdn，2上传元数据到 Hel-pack 数据库（之前这个步骤是在蓝鲸的流水线里由一个插件完成）

[fantasticsoul]

剥离完后，hel-pack 只是个普通的node后台服务 + redis + mysql 即可运行

[fantasticsoul]

hel-pack后台会提供类似这样的接口下发元数据： https://footprint.qq.com/hel/openapi/v1/app/info/getSubAppAndItsVersion?name=remote-lib-tpl

[fantasticsoul]

npm + unpkg 其实也是不错的选择，npm 托管的是源码与类型，unpkg 是个cdn服务，自带版本语义化restful请求，支持独立部署，有用户自己部署私有npm + 私有 unpkg 并搭配hel-micro 使用，优点是轻量与灵活，不过相比 hel-pack，缺乏一些高级功能比如版本回滚，灰度下发等功能。

[OxPatient]

还有完整的看代码，代码基本跑起来了，不清楚如何配置远程加载

我先提交个PR

[fantasticsoul]

可参考这个demo

https://github.com/hel-eco/hel-demo-use-remote-vue-comp/blob/main/src/main.js

[fantasticsoul]

关于cli有什么好的建议么，我的初步想法是，基于hel命令可以快速创建一些预设的项目、组件什么的，例如：

hel create recect-comp // 创建一个react远程组件模板

或者是触发选择

hel create
____
> react comp
> vue comp
> js lib
> react project
> vue project

[OxPatient]

可参考这个demo

https://github.com/hel-eco/hel-demo-use-remote-vue-comp/blob/main/src/main.js

我试下这个demo

[OxPatient]

关于cli有什么好的建议么，我的初步想法是，基于hel命令可以快速创建一些预设的项目、组件什么的，例如：

hel create recect-comp // 创建一个react远程组件模板

或者是触发选择

hel create
____
> react comp
> vue comp
> js lib
> react project
> vue project

我的认为CLI需要包含以下能力：

1. 初始化项目：项目模板、项目配置等
2. 构建命令：start 、 build 等
3. 部署命令：deploy（按项目类型、项目配置，部署到npm、hel-pack，或者其它）

[OxPatient]

monorepo改造已PR， https://github.com/tnfe/hel/pull/17

[fantasticsoul]

monorepo改造已PR， #17 👍🏻，提了个评论你看下哈

[OxPatient]

增加prettier代码格式化规范检查，并格式化项目代码

https://github.com/tnfe/hel/pull/17/commits/26567b7e4a31f4d8d2c5874d19de27c573128f91

[fantasticsoul]

格式化支持指定目标目录吗，例如

npm run format --dir=packages/hel-micro

[fantasticsoul]

发现仅首次格式化慢，后面有了cache后快很多了

[OxPatient]

格式化支持指定目标目录吗，例如

npm run format --dir=packages/hel-micro

要支持指定目录，只须将format命令和prettier配置移到每个子包中

[fantasticsoul]

好的，没关系，仅首次执行慢，后面快很多了

[fantasticsoul]

发现一个问题，仓库里 templates 下的项目用 package.json/dependencies 用 workspace:*描述依赖没有问题，链接他们的依赖到仓库里其他子模块位置，方便做调试，但 packages 里的各个子模块用 workspace:*的话，如果发包了，使用方使用npm 安装会报错 npm ERR! Unsupported URL Type "workspace:": workspace:*

必须切换为yarn命令

为了不破坏使用方的命令行工具使用习惯，packages 不再使用workspace:*，例如hel-micro依赖了hel-micro-core，packages.json文件里的描述也不再使用workspace:*（留意了 vue3的mono仓库里的子项目 https://github.com/vuejs/core/blob/main/packages/runtime-dom/package.json，也没有使用 workspace:*，指向仓库的其他模块依赖）

[fantasticsoul]

遇到一个格式化问题，已替换prettier为另一个版本 https://github.com/tnfe/hel/issues/20

[kumv-net]

巨佬 hel-pack 进展如何

[fantasticsoul]

这个工具剥离出来还需要不少时间，建议先走 unpkg 私服模式