|
什么是 uni_modules
uni_modules是uni-app的插件模块化规范(HBuilderX 3.1.0+支持),通常是对一组js sdk、组件、页面、uniCloud云函数、公共模块等的封装,用于嵌入到uni-app项目中使用,也支持直接封装为项目模板。
插件开发者,可以像开发uni-app项目一样编写一个uni_modules插件,并在HBuilderX中直接上传至插件市场。
插件使用者,可以在插件市场查找符合自己需求的uni_modules插件,使用HBuilderX 3.1.0+直接导入到自己的uni-app项目中。后续还可以在HBuilderX中直接点右键升级插件。
相对于普通的插件,uni_modules插件拥有更强的独立性,拥有独立的目录结构,可以更加方便的发布,更新,卸载(HBuilderX 3.1.0+对uni_modules插件提供了右键菜单,支持发布,更新,安装依赖等)
相对于node_modules(node.js模块),uni_modules的三方依赖安装时默认最新版本,插件均直接安装在uni_modules目录下,不做嵌套,当然,如果开发者希望固定某个版本的依赖,可以将该三方依赖包含到自己的插件包内。
为什么有了node_modules,还需要再发明一个uni_modules的轮子?
node_modules 不满足云端一体的需求。uniCloud的云函数、公共模块、schema和前端的各种js_sdk、组件、页面、项目,无法在node_modules模式下有效融合。
uni_modules有付费和商业的插件,DCloud插件市场提供了版权保护。而node_modules不支持付费和版权保护。
node_modules 是开发者友好而影响终端用户性能的模式。开发者为了省事,层层嵌套node_modules,造成数量惊人的文件数目。uni_modules不支持module嵌套,鼓励开发者优化包体积
uni_modules鼓励开发者总是使用最新版。并在HBuilderX中提供了版本内容对比工具
uni_modules里也支持放置node_modules,没有强行排斥。
与之前插件市场的普通插件相比,uni_modules有何优势?
支持在HBuilderX里直接发布、更新、删除
支持依赖(在package.json中配置)
插件文件位置统一,不会造成下载一个插件,不知道给工程下多少个目录写入了多少个文件。删除插件时也可以一点删除
目录结构
uni_modules插件如果是项目类型的插件,只需要在项目的根目录下放一个符合uni_modules规范的package.json。
如果是非项目类型的插件,比如组件、js sdk、页面模板、云函数,则需要放置在项目的uni_modules目录下。
此时uni_modules目录下的目录结构和uni-app的项目结构是一致的,如下:
uni_modules 项目根目录下
└── [plugin_id] // 插件 ID
├── uniCloud 插件内的uniCloud内容会被虚拟合并到项目根目录的uniCloud中(注意:插件内的uniCloud目录,没有-aliyun,-tcb后缀)
├── components 符合vue组件规范的uni-app组件目录,支持easycom规范
├── hybrid 存放本地网页的目录,详见
├── pages 业务页面文件存放的目录
├── static 存放应用引用静态资源(如图片、视频等)的目录,注意:静态资源只能存放于此
├── wxcomponents 存放小程序组件的目录,详见
├── license.md 插件使用协议说明
├── package.json 插件配置,必选(除此之外均可选)
├── readme.md 插件文档
├── changelog.md 插件更新日志
├── menu.json 如果是uniCloud admin插件,可以通过menu.json注册动态菜单,详见 menu.json 配置
Tips
插件目录不支持pages.json、App.vue、main.js、manifest.json、uni.scss文件,如果需要插件使用者修改这些文件内容,请在插件文档(readme.md)中详细说明。
在插件内部引用资源、跳转页面时,请尽量使用相对路径。
插件内components目录同样支持easycom规范,插件使用者可以直接在项目中使用插件内符合easycom规范的组件,当项目或插件内存在easycom组件冲突,编译时会给予提示,您可以通过修改组件目录及组件文件名称来解决冲突问题。
|
|