Koishi 插件市场官方源提供的插件大小是经过实际安装分析而来的
而 k-r 组织内市场源的三方实现中暂时不包含支持提供实际大小的实现
若您功能有需求, 请在下方投票反馈, 我们会考虑实现相关分析功能, 并公开发布, 感谢您的配合
- 需要该功能, 进行静态分析(扫描插件所有依赖计算大小)
- 需要该功能, 进行动态分析(实际安装该插件计算 n_m 大小)
- 不需要该功能, 只显示插件包的解包大小
- [其他] 请在下方留言
0
投票人
2 个赞
哦对 还有 WebUI 相关功能
- WebUI / 插件发布分类
- WebUI / 插件市场预览
- WebUI / 插件分析查看
- 无
0
投票人
以及特殊请求参数
- 特殊请求参数 / 包含弃用插件
include_deprecated - 特殊请求参数 / 包含隐藏插件
include_hidden - 特殊请求参数 / 包含不兼容的插件 (不声明 peerDep Koishi ^4 的插件)
include_bad_peerdep - 无需这项功能
0
投票人
2 个赞
可是动态分析会让分析过程变慢
谁知道运行包管理器的话会不会卡住诶
还得放到沙盒里分析的说
2 个赞
插件市场可能得对兼容性做一个提示。比如它经过作者声明还是它自己的内部自检的检查。例如用到了哪些只争对某项适配器的功能做的尝试、不支持哪些适配器
最好提供一个支持的适配器图标啊这类的（ 虽然梦做的有点大 ）
插件市场很多插件下之前没有对应文档和提供的指令集。或者能有弹出层能弹出文档、绑定社区页也倒是可以尝试。
其他的扩展不能说没太大作用，倒是感觉无伤大雅…
2 个赞
理论能实现，但是得从修改market插件进行了，需要fork一个market-next之类的然后分发也是个问题
2 个赞
会做的会做的, 但是最近几个月事情多
1 个赞
@: 考虑市场源同时提供 npm meta 数据(
/: 但是若捣鼓出来整个插件依赖树然后设置白名单,
感觉实现起来的效率不高, 得先实现详细分析
要么全都允许, 那么可能会有恶意使用的问题
1 个赞