关于 devui-cli 的一些想法

[TinsFox]

👋 Welcome!

我们正在讨论devui-cli devui开源生态上的基建问题:

在devui 的背书下，笔者认为单纯得去建立几个React、Vue、Angular 的UI库出来并没有很大的意义和作用，当然意义还是有的，只不过相对来说就稍小了，影响力以及作用效果都不够。在UI库中可以学习到源码的编写逻辑、样式布局以及API的暴露，但是笔者觉得这些是业务层面的学习，但是在前端领域方面，想要进步晋升，单纯是业务方面的学习是远远不够的，只有这些也就只是三五年的切图仔而已。另一方面，笔者觉得前端开发者需要学习的事工程化方面的知识，什么是工程化、怎样去做工程化、工程化能带来什么样的作用。

在这里主要是先讨论下 devui 的基建问题，也就是基础建设。如果 devui 是准备建立健全一整个开发生态的话，那么基建是必不可少的。这里的基建，笔者认为是在cli层面去做的一些事情。这并不是 umijs、modernjs所做的事情。这里我们先讨论的是对生态所提供的帮助，对生态的使用者以及生态的共建者所能做的一些事情，在cli层面就去实现它。

cli 功能及其目的

文档渲染

在现在的vue-devui 的开发中，文档的构建使用的是 vitepress。在阅读仓库的源码过程中，笔者发现了一些问题（老强迫症患者了🤣）。

• 文档与组件的源码是割据开来的。
  什么意思呢？就是组件的源码存放于/vue-devui/packages/ devui-vue/devui下，但是起对应的文档却是在vue-devui/packages/devui-vue/docs/components下，组件的贡献者不知道有没有这样的感觉：组件写好了，文档要翻到其他目录下去找，组件多了之后还会有点找不到的小烦躁。
  这就是因为使用 vitepress 的后果，vitepress约定式markdown文档就是要放在 doc 目录下（当然也可能是有解决办法，目前还没发现），这没办法啊，用了别人的东西就得遵守别人的游戏规则，除非是开发了接口给你去扩展。

• 在Markdown里书写demo代码
  现在去写组件的demo是在markdown里书写，使用 :::demo 去包裹，应该是会有一个困扰，写代码没有提示补全功能。（哇，这是什么人间疾苦，面试手撕算法么 🌚）。

• 主题的配置问题
  不知道有没有同学发现，运行组件库的时候执行的脚本是 "dev": "yarn generate:theme && vitepress dev docs", 和 "predev": "node ./devui-cli/index.js create -t vue-devui --ignore-parse-error", vue-devui 的主题是拷贝了vitepress 的源码过来进行修改的，这说明这种第三方的库的使用的局限性，自由度目前还是不能够满足使用。

组件代码编译&构建

• vue-devui 的源码使用 tsx 编写，一般的项目是不能直接使用的，需要经过编译，输出生产环境的包，可以使用webpack、vite进行这项工作，还可以结合 esbuild 进一步提高打包速度，这里笔者不是很了解，就不过多地展开了。
• 在编译和构建方面，笔者觉得可以多方并存，webpack 构建发行包；vite 编译开发，根据其特性应用到我们的项目中来。因为开源项目最主要的目的是提高使用者的效率和体验，为使用者带来更大的价值的同时，给开发者提供场景需求，应用所学，给自己带来提升。

团队规范

团队规范也是基建的一个问题，这个的建设在初期会耗费大量的精力，但是成效确实很难看到的。因为他就是一个不痛不痒的东西，既不会提升你编码的技巧水平，也不会对代码的性能有非常大的提升，但是这不妨碍我们花大量的时间经历去整理这个规范。这些东西完全可以集成几个库，发布到npm上去，方便习惯这些规范的同学拿到个人或者是公司的项目中去实践。

• contribution
• editorconfig
• eslint
• prettier
• stylelint
• changelog

目的

其实上面说了那么多的废话，总结起来就是 我们打算全部自己做! 也欢迎社区的小伙伴一起参与进来共建[握手]。
没错，就是在允许的情况下，所有东西都由咱们 devui 生态来完成，文档系统、组件的编译构建流程 webpack/vite的配置、规范的制定。
可能会有同学说，设想那么大，吃得下吗？那一口必然是吃不下的，可以循序渐进的嘛。比如文档提醒，现在没有，那就使用vitepress过度，devui-cli 不也是一步步从仓库的重构中走到现在，慢慢地抽离出来吗？一切都是为了方面开源贡献！

devui-cli 功能点

关于 devui-cli 的一些功能点，笔者做了一个简单的 road map：

前期会与某个框架耦合（react/vue）

• 文档系统，暴露约定式配置读取markdown 文件，渲染文档
• 文档展示demo，在markdown 中 使用 :::demo 等代码块的方式，支持react组件库的demo展示
• 脱离react约束，暴露vue、ng组件库的demo展示，完全解耦应该是做不到的，因为要渲染某一个框架的demo，其载体还是基于那个框架会比较方便实现。
• 引入外部demo代码块，参照 dumi 实现，这样就可以解决在markdown中编写demo的问题了。
• eslint
• prettier
• stylelint
  未完待续