RFC : modern omi in 2022
ChelesteWang opened this issue · comments
这里提出几个 RFC 为腾讯开源人才培养计划的 Omi 项目作为预热，用来优化 Omi 生态开发的整个流程，优化 Omi 开发工具链，以及优化 Omi 组件库的整体结构。
- 尝试最低成本迁移到 monorepo 优化整个开发体验
- 移除强平台性依赖如 node-sass 等降低开发踩坑难度
- 优化整个组件库编译打包流程，尽可能收口同一个构建流程中。
- 优化整个脚手架开发体验 , 为后期的整个 proform protable 等复杂组件做铺垫
- 规范化代码检查与风格化
- omiu demo 调试开发优化
很棒的想法👍
RFC 1 : 尝试最低成本迁移到 monorepo 优化整个开发体验
目前 omi 以一个类 monorepo 的形式进行代码管理，但没有完整的 monorepo 的工具链以及依赖管理机制，开发中较为复杂，拟尝试使用 pnpm workspace 对 omi 进行 monorepo 支持。pnpm 相比于 lerna 方案基本没有侵入性，改造成本较小，开发体验与开发效率能有较大提升，pnpm monorepo 方案也是当前社区的主流方案。
TODO:
- pnpm 改造 monorepo 消除隐式依赖
- changesets 优化 monorepo 开发流程，打包构建发布
pull request：
RFC 2：移除强平台性依赖如 node-sass 等降低开发踩坑难度
在去年的整体开发中 omiu 强依赖于 node-sass 导致很多同学开发中都遇到过 node-saas 版本与 node 不匹配的问题，在调试过程中 windows 环境下 node-gyp 也不是很友好，很多依赖包还依赖于网络环境，因此提出此 RFC 拟用 Dart-sass 无痛迁移整个 omiu 中的 node-sass 。
TODO：
- 移除 rollup-plugin-sass 依赖，替换为 rollup-plugin-postcss 统一使用 postcss 对样式文件进行处理
pull request： #743
RFC 3：优化整个组件库编译打包流程，尽可能收口同一个构建流程中。
在去年的开发中，我们的组件并没有一个通用的编译发包流程，每一个组件强依赖于一个包，整体开发流程不是很通畅，因此改造后向现在主流组件库对齐，可以通过通用流程配置去进行打包。并支持按需引入以及Tree Shaking 。降低各个组件之间的强耦合，减少重复模板代码。
TODO：
- 通用编译打包构建流程
- 是否接入 vite 进行打包
- 统一开发与生产环境产物，移除 webpack 开发时构建
pull request：
RFC 4：优化整个脚手架开发体验 , 为后期的整个 proform protable 等复杂组件做铺垫
配合 RFC 3 优化脚手架 create-omi 的整个功能，尝试使用微生成器等方式优化整个开发体验，统一整体开发规范。尝试接入 github 提供的 CI / CD 补齐整个研发流水线。为后续复杂组件保驾护航。保证开发效率与组件质量。
TODO:
- 接入统一编译构建流程，改造工程目录，组件同级不关注打包细节
pull request：
RFC 5：规范化代码检查与风格化
逐步统一 eslint 配置，接入代码格式审查与风格化审查，统一整体项目的风格
TODO:
- RFC 4 改造后的工程结构可以将 eslint 等审查格式化移到外面
- 优化现有项目 eslint 审查与风格化
- 提出 omiu 子项目及其他子项目 eslint 规范
pull request：
1.支持尽快迁移到 pnpm + monorepo 的形式
2.node-sass干掉
3.优化整个组件库编译打包流程，尽可能收口同一个构建流程中
这个会不会导致开发单个组件编译耗时变长？每个组件不能独立发布？
3.优化整个组件库编译打包流程，尽可能收口同一个构建流程中
这个会不会导致开发单个组件编译耗时变长？每个组件不能独立发布？
是可以独立发布的，编译的流程统一到外部，不会全量打包，整体组件产物不会受构建流程影响
- 支持 pnpm + monorepo 与 sass 的迁移。
其他建议：
- 可通过编写
scripts/build.mjsscripts/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): xxxfix(admin): xxx
- 添加新功能：
一直看omi没迭代动静，基于omi 又自己造轮子了 https://wu-component.github.io/
一直看omi没迭代动静，基于omi 又自己造轮子了 https://wu-component.github.io/
为啥不基于omi搞
最早是用omi的，但于Lit相比缺了装饰器方式定义，后来就基于 Omi 搞了几个装饰器。
RFC 1 : 尝试最低成本迁移到 monorepo 优化整个开发体验 目前 omi 以一个类 monorepo 的形式进行代码管理，但没有完整的 monorepo 的工具链以及依赖管理机制，开发中较为复杂，拟尝试使用 pnpm workspace 对 omi 进行 monorepo 支持。pnpm 相比于 lerna 方案基本没有侵入性，改造成本较小，开发体验与开发效率能有较大提升，pnpm monorepo 方案也是当前社区的主流方案。
TODO:
- pnpm 改造 monorepo 消除隐式依赖
- changesets 优化 monorepo 开发流程，打包构建发布
pull request：
已经有pr了么？