cc-plugin
专为Cocos Creator
插件开发的cli,一次编写,同时发布v2,v3版本,免去多版本同步的问题。
具体实现原理就是使用webpack抹平了v2、v3插件版本的底层差异,借助cli,使开发插件更加工程化。
目前使用typescript开发插件,体验更加丝滑流畅。
赶快 npm install cc-plugin -g
,开启一段美妙的开发旅程吧!
为什么要开发cli
我自己本人有10余款插件,当creator 3.x
发布后,看到新的插件系统,我既高兴
又悲伤
,又是一堆的适配体力活。
当适配了2款插件后,我犹豫了,这种开发体验不是我所希望的,等于我的工作量增加了一倍,但是对外产出却没有发生实质性的变化。
我渴望有这么一个framework
能够处理好差异,让插件开发更加专注于业务逻辑。
近2年的时间,我很少再更新插件,并且也很少维护插件了,业余时间我就开始琢磨这件事。
期间亲自体验了vscode
、jetbrains
插件开发流程,也尝试着从中寻找一些灵感。
之前参与的一个项目,我一直都在尝试着要把开发体验更加工程化,但每天被业务逻辑缠身,这件事也就成为了一个未了的心愿。
随着项目的发展,这件事也就慢慢提上了日程,正是这些宝贵的经验,让cc-plugin
成为了可能。
痛点&亮点
cc-plugin的亮点是建立在creator插件开发的痛点之上,这种滋味,只有体会过的人才会深知。
使用 typescript
+ vue
开发面板
typescript的类型推断,大大提高了开发效率,编码体验一级棒。
轻量简单易学的vue,大大降低了插件面板的开发难度。
这套组合,毋庸置疑,是当前最流行、最受欢迎的。
当然,react后续也可以支持一下。
完美适配所有版本的creator
插件在不同的creator版本上运行,总是存在这样那样的适配问题。
不但使用上存在差异,而且表现上也存在差异,最主要的问题集中在:
适配:UI组件
起初我是根据不同的版本,对使用到的ui组件进行调整,但是这样带来一个恶心的问题
举个栗子,不代表插件目前存在这样的情况,比如ui-button
的点击事件:
在1.x版本中这样写
<ui-button @confirm="onClick">按钮</ui-button>
在2.x版本中这样写
<ui-button @click="onClick">按钮</ui-button>
相同的功能,写法发生了变化,为了适配,我可以这么写
<ui-button @click="onClick" @confirm="onClick">按钮</ui-button>
这样又带来了新的问题:
- 如果这么写,我就需要每个ui-button都这么写,而且还要承担未知的风险。
- 如果不这么写,我就需要维护2套代码。
这还是相同功能,不同版本写法差异的适配,如果是功能之间的丢失,这就更要命了。
解决方案
cc-plugin内置的一套ui组件,从根本上杜绝了这个问题。
有舍必有得:
- cc-plugin的内置组件,需要一步一步从0开始编写,特别是那些跟编辑器自身关联比较密切的组件,比如cc-asset等,有可能就无法实现了。
- ui组件的使用统一,表现统一,无需二次适配。
这里并没有采用第三方的vue组件,因为集成后存在比较多的问题。
现在大部分插件功能都比较单一,基本的按钮、输入框、选择器等都能满足需求。
如果交互非常复杂,一般情况下都需要自己实现。
这也是cc-plugin开源的一个原因,开发者可以实现更多功能的ui组件,然后提交到仓库,让更多的人受益。
毕竟,web前端的入门难度偏低、从业人数巨大!
适配:编辑器接口
随着编辑器的功能逐步完善,追加的功能也越来越丰富。
大致需要适配一下几个方面:
- 相同的功能,使用方法也发生了变化。
- 低版本的部分接口被逐步废弃,调用这些废弃的接口会导致警告。
- 不同的编辑器版本,使用的electron版本也发生了变化。
解决方案
cc-plugin自身提供了一套对外接口,插件是运行在这套framework之上,底层抹平这些差异。
适配代码的沉淀
随着cc-plugin
的逐步完善,上述提到的所有适配问题,也会逐步跟进,使用cc-plugin
开发的每一个插件,都无须再去做额外的适配工作。
至少不用每个人都去研究适配的问题了,前人栽树后人乘凉。
创建插件
因为是基于cli,所以在设计时,也参考了vue-cli,推荐全局安装。
cc-plugin内置了demo模板,通过
ccp create my-plugin
这样就可以在当前目录下创建一个demo插件。
发布插件
-
代码自动压缩混淆、tree shaking。
-
一键打包zip,方便store上传。
比如上传store需要的icon,有分辨率的要求,cc-plugin也会自动裁切。
如果可能,未来也许有更多的机会和store联动。
还有哪些想法
- 插件的HMR(hot module replacement),让开发效率起飞
目前仅仅实现了hot reload,可以理解为F5,而HMR无须刷新,直接刷新热替换内存,HMR存在一定的技术难度,目前暂未实现。
- 更加友好的报错体验。
webpack最让人恐惧的就是它的配置,让人头皮发麻,对新手不是太友好,虽然cc-plugin已经尽可能的隐藏这部分配置,但是当遇到问题时,还是需要有一定的webpack基础才能快速定位到问题。
- 更快的面板UI编写效率
这部分本身就是基于web技术开发的,前期实现UI逻辑时,是可以脱离编辑器,在浏览器中运行调试,进一步提升开发效率。
- 一键转化为vscode插件
我想pr代码
目前仅仅是初期版本,只完善了基础功能,期望更多的小伙伴加入。
如果你想要和我一起完善cc-plugin,需要基本掌握以下的部分技能
即可:
-
有一定的creator插件编写经验,这样可以发现更多的需求
-
对webpack、vue要比较熟悉,掌握webpack plugin、webpack loader的编写
-
简单了解ast
当然,还有更多的技术细节,使用了比较多的node package,遇到问题,求人不如求己,还是看源码吧兄弟!有些问题我也是这辈子第一次遇到。
结语
完成cc-plugin的第一个版本,还是学到了非常多的新知识。
期间查阅了不少的技术资料,差一点放弃!还好还好,咬牙过来了!
感谢公司的栽培,还有家人的支持,相信这句话在很多书籍的序言中都有出现,也许只有亲身经历,方知其中滋味。
CC-Plugin
,让插件开发更简单。
对插件开发有用的小工具
npm i @xuyanfeng/cc-editor -g
插件开发过程中需要在不同的creator版本进行自测,通过 cc-editor 快速切换配置项,而且cc-editor自身还增加了调试主进程的参数,提高插件开发效率。