How about include the dev scripts in this pkg?

[northword]

Ref: windingwind/zotero-plugin-template#94 (comment)

话说，toolkit 有没可能把开发相关的脚本也加进去呢？类似 https://github.com/retorquere/zotero-plugin 那样的，或者新开一个包，

把 start.mjs / server.mjs / build.mjs / release 都包括进去，这样多插件的开发者以后更新起来可能会比较方便；
目前插件模板的结构与 retorquere 的差别比较大，所以 zotero-plugin 对插件模板这样结构的不太友好，而且 retorquere 的那个发布流程是基于分支的，对比咱们现有的比较复杂。

通过 .env 包读取两个配置文件，一个配置文件为现 zotero-cmd.json 里的东西，包含 zo 目录，profile 目录；另外还需要一个不与开发者本地有关的配置文件，例如 esbuild 入口等。

[northword]

可以单独开一个包；但是考虑到现在和toolkit功能上的依赖，也可以放在toolkit里面，有啥想法考虑？

如果新开一个包， toolkit 与这个包相互依赖的部分可以移过去不？可以移过去的话，toolkit 就是一个依赖项，另一个新包就是一个开发依赖，我觉得能分开当然最好，分不开的话放一起也可以接受 （五五开）

[windingwind]

依赖的部分基本上是插件编译以后在zo里面运行的部分，如果只是在node层面的依赖倒是方便。
也许可以把debug-bridge部分从toolkit包剥离出来；但是始终需要插件里面import这个包，不是很方便，有些开发者可能会有顾虑？

两种替代方案：

1. 这个包在编译/启动时自己编译一个插件，用于debug和通信等，安装进zo
2. 这个包在index.js里注入内容，实现debug和通信等

[northword]

1. 这个包在编译/启动时自己编译一个插件，用于debug和通信等，安装进zo
2. 这个包在index.js里注入内容，实现debug和通信等

二选一的话，我倾向于第一种，我觉得如果是作为一个开发依赖的话，最好可以做到不修改正在开发的插件。

[windingwind]

我同意。同时也可以在这个内置的开发用插件的基础上用于实现并测试这个包的功能，试验一下我们之前讨论的插件测试流程，感觉不错

[northword]

如果加进去这些脚本，需不需要考虑不是 zotero-plugin-template 模板这样目录结构的插件？

[windingwind]

涉及build这类的操作，不太可能支持其他类型的插件结构；不然和自己重写一个build也没有区别了。

可以把build类做成可重载的/支持plugin的形式；但是会增加复杂性

[northword]

或者提供一个选项允许覆盖默认的 build 就可以？（这应该也是后期的事情了，前期肯定是以 template 的结构先写）