Feature: 将指令视为服务

[Lipraty]

Describe the problem related to the feature request

不同插件提供了同一个命令在启动时 koishi 会直接报错

Describe the solution you'd like

类似服务重复提供提示，为指令提供冲突提示

Describe alternatives you've considered

• (braking)要求开发者在 pkg.json 中加入比如 contributions 字段来注册指令，这样可以在加载前提示冲突。
• 直接抛出错误，并 dispose 冲突的两个插件（这些目前的行为吗？）

Additional context

No response

[shigma]

个人建议：

1. 将指令视为服务，例如 command:help
2. 直接将服务写进 koishi.service.implements 中

这样也能实现上述需求，并且统一性更强。

但这样一来这个 issue 就应该回到 Koishi 仓库了。是谁把它 transfer 过来的呢？

[Lipraty]

我是笨蛋

---

Generated by koishi-plugin-github.

[shigma]

当前版本中，尽管存在冲突指令时会报错，但是 Koishi 仍然能正常启动，只是其中一个插件启动失败而已。失败的插件仍然会产生可读的日志信息，因此实际上问题并不严重。

将指令视为服务是一个很好的思路，它可以明确表达插件对指令的依赖关系，并规避潜在的冲突。然而，某些插件提供了大量指令。如果直接要求所有插件都声明自己提供的指令，我担心会增加开发者负担。如果此行为是非强制性的，那么开发者恐怕并不会调整自己的插件，因此上述问题依然存在；如果是强制性的（即使只是给出警告），已经不再活跃更新的旧插件一经启动就会产生大量错误信息，这并不是我们希望看到的。

[CyanChanges]

让两个指令都能用就好了（

exec: 当前指令有多个实现，请选择你要调用的指令：
(spawn) exec [command]: 执行命令
(SUStools) exec (alias of taskadd) [-p <id>] cmd: 执行任务

[shigma]

让两个指令都能用就好了

指令调用要提供给其他插件作为 API 调用，所以必然不能这么设计。否则插件可能会在没人说话的时候来一句请选择了。

[CyanChanges]

让两个指令都能用就好了

指令调用要提供给其他插件作为 API 调用，所以必然不能这么设计。否则插件可能会在没人说话的时候来一句请选择了。

除非是预装插件，不然没办法保证这个指令被实现/用法一样
就和服务类似，应该可以指定使用哪个插件注册的指令，毕竟指令名字重复不重复是很难知道的（package.json 目前没有相关字段

[shigma]

除非是预装插件，不然没办法保证这个指令被实现/用法一样 就和服务类似，应该可以指定使用哪个插件注册的指令，毕竟指令名字重复不重复是很难知道的（package.json 目前没有相关字段

由服务的提供者规定服务的行为，由服务的使用者决定使用谁的服务。本身这就不是强制的。指令同理。