omi RFC : modern omi in 2022

这里提出几个 RFC 为腾讯开源人才培养计划的 Omi 项目作为预热，用来优化 Omi 生态开发的整个流程，优化 Omi 开发工具链，以及优化 Omi 组件库的整体结构。

尝试最低成本迁移到 monorepo 优化整个开发体验
移除强平台性依赖如 node-sass 等降低开发踩坑难度
优化整个组件库编译打包流程，尽可能收口同一个构建流程中。
优化整个脚手架开发体验 , 为后期的整个 proform protable 等复杂组件做铺垫
规范化代码检查与风格化
omiu demo 调试开发优化

Jun 26 '22 15:06 ChelesteWang

很棒的想法👍

Jun 26 '22 15:06 BoyYangzai

RFC 1 : 尝试最低成本迁移到 monorepo 优化整个开发体验目前 omi 以一个类 monorepo 的形式进行代码管理，但没有完整的 monorepo 的工具链以及依赖管理机制，开发中较为复杂，拟尝试使用 pnpm workspace 对 omi 进行 monorepo 支持。pnpm 相比于 lerna 方案基本没有侵入性，改造成本较小，开发体验与开发效率能有较大提升，pnpm monorepo 方案也是当前社区的主流方案。

TODO:

[x] pnpm 改造 monorepo 消除隐式依赖
[x] changesets 优化 monorepo 开发流程，打包构建发布

pull request：

Jun 26 '22 16:06 ChelesteWang

RFC 2：移除强平台性依赖如 node-sass 等降低开发踩坑难度在去年的整体开发中 omiu 强依赖于 node-sass 导致很多同学开发中都遇到过 node-saas 版本与 node 不匹配的问题，在调试过程中 windows 环境下 node-gyp 也不是很友好，很多依赖包还依赖于网络环境，因此提出此 RFC 拟用 Dart-sass 无痛迁移整个 omiu 中的 node-sass 。

TODO：

[x] 移除 rollup-plugin-sass 依赖，替换为 rollup-plugin-postcss 统一使用 postcss 对样式文件进行处理

pull request： #743

Jun 26 '22 16:06 ChelesteWang

RFC 3：优化整个组件库编译打包流程，尽可能收口同一个构建流程中。在去年的开发中，我们的组件并没有一个通用的编译发包流程，每一个组件强依赖于一个包，整体开发流程不是很通畅，因此改造后向现在主流组件库对齐，可以通过通用流程配置去进行打包。并支持按需引入以及Tree Shaking 。降低各个组件之间的强耦合，减少重复模板代码。

TODO：

[ ] 通用编译打包构建流程
[ ] 是否接入 vite 进行打包
[ ] 统一开发与生产环境产物，移除 webpack 开发时构建

pull request：

Jun 26 '22 16:06 ChelesteWang

RFC 4：优化整个脚手架开发体验 , 为后期的整个 proform protable 等复杂组件做铺垫配合 RFC 3 优化脚手架 create-omi 的整个功能，尝试使用微生成器等方式优化整个开发体验，统一整体开发规范。尝试接入 github 提供的 CI / CD 补齐整个研发流水线。为后续复杂组件保驾护航。保证开发效率与组件质量。

TODO:

[ ] 接入统一编译构建流程，改造工程目录，组件同级不关注打包细节

pull request：

Jun 26 '22 16:06 ChelesteWang

RFC 5：规范化代码检查与风格化逐步统一 eslint 配置，接入代码格式审查与风格化审查，统一整体项目的风格

TODO:

[ ] RFC 4 改造后的工程结构可以将 eslint 等审查格式化移到外面
[ ] 优化现有项目 eslint 审查与风格化
[ ] 提出 omiu 子项目及其他子项目 eslint 规范

pull request：

Jun 29 '22 00:06 ChelesteWang

1.支持尽快迁移到 pnpm + monorepo 的形式 2.node-sass干掉

Jun 29 '22 01:06 dntzhang

3.优化整个组件库编译打包流程，尽可能收口同一个构建流程中

这个会不会导致开发单个组件编译耗时变长？每个组件不能独立发布？

Jun 29 '22 01:06 dntzhang

3.优化整个组件库编译打包流程，尽可能收口同一个构建流程中

这个会不会导致开发单个组件编译耗时变长？每个组件不能独立发布？

是可以独立发布的，编译的流程统一到外部，不会全量打包，整体组件产物不会受构建流程影响

Jun 29 '22 05:06 ChelesteWang

支持 pnpm + monorepo 与 sass 的迁移。

其他建议：

可通过编写 scripts/build.mjs scripts/release.mjs 脚本 cli，传入组件名编译/发布对应组件，将打包配置统一。
可考虑移除 git 中 dist 目录，仅在 npm 中发布。
添加 .github/workflows 使用 GitHub Actions 做 CI/CD
规范 commit 名称，如 angular commit message
- 添加新功能：feat: xxx
- 重构：refactor: xxx
- 修复：fix: xxx
- 样式：style: xxx
- 文档：docs: xxx
- 杂项：chore: xxx
- 针对某个子模块的 scope，如 fix(omiu): xxx fix(admin): xxx

Jun 29 '22 16:06 YunYouJun

一直看omi没迭代动静，基于omi 又自己造轮子了 https://wu-component.github.io/

Jul 06 '22 17:07 canyuegongzi

一直看omi没迭代动静，基于omi 又自己造轮子了 https://wu-component.github.io/

为啥不基于omi搞

Jul 07 '22 04:07 dntzhang

最早是用omi的，但于Lit相比缺了装饰器方式定义，后来就基于 Omi 搞了几个装饰器。

Jul 07 '22 13:07 canyuegongzi

RFC 1 : 尝试最低成本迁移到 monorepo 优化整个开发体验目前 omi 以一个类 monorepo 的形式进行代码管理，但没有完整的 monorepo 的工具链以及依赖管理机制，开发中较为复杂，拟尝试使用 pnpm workspace 对 omi 进行 monorepo 支持。pnpm 相比于 lerna 方案基本没有侵入性，改造成本较小，开发体验与开发效率能有较大提升，pnpm monorepo 方案也是当前社区的主流方案。

TODO:

[x] pnpm 改造 monorepo 消除隐式依赖

[x] changesets 优化 monorepo 开发流程，打包构建发布

pull request：

已经有pr了么？

Aug 18 '22 10:08 qiutian00

omi omi copied to clipboard

RFC : modern omi in 2022

omi
omi copied to clipboard