开发规范
命名规范
Git插件包
这里必须遵守，否则将无法被karin识别启用
- 插件包名称必须以
karin-plugin-开头，后面跟插件名称 - 必须使用英文命名，尽量简短，避免使用特殊符号
- 统一为小写，使用
-连接单词
例如：kritor-plugin-hello 、karin-plugin-my-plugin 、karin-plugin-my-awesome-plugin
单个js
这里是推荐规范，不强制要求
一般情况下 不建议另外再创建一个同样功能的karin-plugin-example文件夹。
- 统一存放在
karin提供的karin-plugin-example - 使用英文进行命名，无固定前缀要求
- 名称尽量简短，避免过长
- 名称避免使用特殊符号，使用
-连接单词
例如：hello-world.js 、my-plugin.js 、my-awesome-plugin.js
结构规范
TIP
建议直接使用 模板仓库 进行开发
插件包的目录结构，请参照以下规范进行组织，开发者可自行在基础结构上进行调整
文件结构
TIP
以下是一个基础的结构规范，具体项目可根据实际情况进行调整
kritor-plugin-hello
├── apps
│ ├── app1.js
│ └── app2.js
├── config
│ ├── config
│ │ ├── config.yaml
│ │ └── user.yaml
│ └── defSet
│ ├── config.yaml
│ └── user.yaml
├── resources
│ ├── template
│ ├── font
│ ├── icon
│ ├── image
│ └── css
├── lib
├── model
├── index.js
├── .gitignore
├── README.md
├── CHANGELOG.md
├── LICENSE
└──package.json数据文件
警告
这里请必须遵守
- 对于
数据文件，karin要求开发者将数据文件统一存放到data/下 karin会在启动的时候，为每一个插件包在data/下创建对应名称的文件夹- 如无特殊需求，请不要在
data文件夹下创建其他文件夹
问：为什么要求统一存放数据文件？
答：方便 karin 统一管理，方便用户 查找、迁移 、快速 备份 。
问：什么样的算数据文件？
答：如 Cookie 、Token 、sqlite 、mysql 等数据文件，不包含 配置文件 、资源文件 。
配置文件
无需一定遵守，但是推荐遵守
- 对于配置文件，由于使用
git进行管理升级，所以一般会有两种配置文件：默认配置和用户配置 Git默认配置：要求统一存放在插件自身的karin/plugin/<plugin_name>config/下，由开发者进行维护修改，此处禁止用户编辑修改。Npm默认配置：要求统一存放在插件自身的karin/node_modules/<plugin_name>config/下，由开发者进行维护修改，此处禁止用户编辑修改。用户配置：要求统一存放在karin/config/plugin/<plugin_name>下，由用户进行编辑修改。- 如无特殊需求，请不要在
config文件夹下创建其他文件夹
对于这里，建议使用
karin-plugin-template作为模板，进行开发
资源文件
任选其一即可，以下是两种常见的规范，无需一定遵守
规范1:
- 插件包的资源文件
- 字体文件存放在
resources/font/下 - 图片文件存放在
resources/image/下 - 图标文件存放在
resources/icon/下 - 通用样式文件存放在
resources/css/下 - 渲染模板存放在
resources/template/下，每一种模板新建一个文件夹
规范2:
- 每一种渲染模板都在
resources下新建一个文件夹，文件夹名称为模板名称，将模板的资源文件存放在该文件夹下
临时文件
- karin会在启动的时候，在
karin/temp下为每一个插件包创建对应名称的文件夹 - 开发者可在该文件夹下存放临时文件，如缓存文件、日志文件等
- 请勿对他人的文件夹进行删除、修改
- 如无特殊需求，请不要在该文件夹下创建其他文件夹。
html渲染模板
- karin会在启动的时候，在
karin/temp/html下为每一个插件包创建对应名称的文件夹 - 请开发者在使用渲染的时候，将
name设置为插件包名称
仓库规范
- 要求插件仓库名称必须以
karin-plugin-开头，必须与插件包名称一致 - 插件仓库必须提供开源协议
- 在仓库标签页，添加
karin、karin-plugin - 对于二改的
karin仓库，必须进行开源，并使用GPLv3+协议，并使用karin标签进行标记
多媒体资源规范
- 网络资源：
- 必须携带
http或https协议 - 如：
https://www.example.com/image.png
- 必须携带
- 本地资源：
- 必须携带
file协议 - 必须使用
file://开头，禁止使用file:///开头 - 同一服务器环境跨应用传输，比如使用
绝对路径 - 如：
file://D:/example/image.png、file:///root/image.png
- 必须携带
base64:- 必须使用
base64://开头 - 不要携带
data:image/png;base64,等前缀 - 如：
base64://iVBORw0KGAYAAR42mL8//8/AyUYw ...
- 必须使用
基本规范
建议开发者在仓库主页添加 免责声明
对于
开源插件，必须提供开源协议。对于
闭源插件，请遵守下方规则即可。禁止存在触犯法律法规的行为
禁止存在侵犯第三方知识产权的行为
禁止存在恶意推广、恶意宣传等恶意行为
禁止存在恶意利用插件进行违法犯罪活动等恶意行为
禁止存在恶意破坏、恶意修改、恶意删除、恶意添加等恶意行为
禁止存在恶意破坏用户隐私、恶意收集用户信息等恶意行为
禁止存在恶意收集、泄露用户数据、恶意泄露用户隐私等恶意行为
禁止存在恶意修改插件的源代码、恶意删除插件的源代码等恶意行为
禁止在插件中包含任何形式的 后门、木马 、病毒 等恶意代码或程序
对于加密、混淆的插件，必须在仓库主页声明哪些文件是加密、混淆的，并注明代码混淆的目的
问：为什么要求遵守这些规范？
答：君子协议。我们希望开发者能够遵守这些规范，让 karin 生态更加健康，让开发者和用户更加放心。
问：为什么必须提供开源协议？
答：
- 在很多人的印象中，开源就是免费的，但是开源并不代表免费，开源是一种精神，是一种对社区的贡献，是一种对开发者的尊重。
- 开源协议可以保护开发者的权益，让开发者的劳动成果不被滥用。
- 大多数情况下，没有开源协议的插件，在产生纠纷的时候，往往双方都无法得到一个好的处理结果。
- 并且部分开源协议支持商业使用，开发者可实现商业化，从中获取一定的收益。
