This repository has been archived by the owner on Nov 24, 2022. It is now read-only.
关于 devui-cli 的一些想法 #1
TinsFox
started this conversation in
Show and tell
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
👋 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 的源码过来进行修改的,这说明这种第三方的库的使用的局限性,自由度目前还是不能够满足使用。组件代码编译&构建
团队规范
团队规范也是基建的一个问题,这个的建设在初期会耗费大量的精力,但是成效确实很难看到的。因为他就是一个不痛不痒的东西,既不会提升你编码的技巧水平,也不会对代码的性能有非常大的提升,但是这不妨碍我们花大量的时间经历去整理这个规范。这些东西完全可以集成几个库,发布到npm上去,方便习惯这些规范的同学拿到个人或者是公司的项目中去实践。
目的
其实上面说了那么多的废话,总结起来就是 我们打算全部自己做! 也欢迎社区的小伙伴一起参与进来共建[握手]。
没错,就是在允许的情况下,所有东西都由咱们 devui 生态来完成,文档系统、组件的编译构建流程 webpack/vite的配置、规范的制定。
可能会有同学说,设想那么大,吃得下吗?那一口必然是吃不下的,可以循序渐进的嘛。比如文档提醒,现在没有,那就使用vitepress过度,devui-cli 不也是一步步从仓库的重构中走到现在,慢慢地抽离出来吗?一切都是为了方面开源贡献!
devui-cli 功能点
关于 devui-cli 的一些功能点,笔者做了一个简单的 road map:
未完待续
Beta Was this translation helpful? Give feedback.
All reactions