RFC : modern omi in 2022

[ChelesteWang]

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

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

[BoyYangzai]

很棒的想法👍

[ChelesteWang]

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

TODO:

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

pull request：

[ChelesteWang]

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

[ChelesteWang]

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

TODO：

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

pull request：

[ChelesteWang]

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

TODO:

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

pull request：

[ChelesteWang]

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

TODO:

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

pull request：

[dntzhang]

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

[dntzhang]

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

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

[ChelesteWang]

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

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

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

[YunYouJun]

• 支持 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

[canyuegongzi]

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

[dntzhang]

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

为啥不基于omi搞

[canyuegongzi]

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

[qiutian00]

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

TODO:

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

pull request：

已经有pr了么？