观看 @koishi/scripts 我们可以知道 yarn new 新建的空插件里的 tsconfig.json 是对 template 里的 tsconfig.json 进行一些补充得到的
我本地工作区里的插件起码有三个不同版本的 tsconfig.json，这好像有点坏
2 个赞
如果你不打算把你的插件独立使用，比如独立上传到 GitHub，那么你直接这么写：
如果你要独立使用就不行
1 个赞
If you are going to share your tsconfig.json in multiple workspaces, you could also publier your tsconfig into a single package, which I did for my bot before, just like vue recommended:
Then you install the package as the devDependencies in your workspace, add this line to your tsconfig.json:
{
"extends": ["@scoped/tsconfig"]
}
2 个赞
好方略，不过我想稍作修改。
{
"extends": ["@koishijs/scripts/template/tsconfig.base"]
}
现在才知道这里可以不用相对路径
2 个赞
咦 可以这么用吗 感觉不太妙
2 个赞
和上面那个原理应该是一致的
3 个赞
原理是一致的，但 scripts 这个包没有稳定性保证，他随时可能在一个 patch 版本修改这个文件的位置
2 个赞
I don’t think so, since you can lock the version of any tsconfig package, you can also lock the version of scripts package.
4 个赞
对任何一个包来讲，都可以锁定一个版本，然后尽情使用这个版本里的 bug，或是没有稳定性保证的 API。但我确实觉得这不太妙，所以我才说「不太妙」。锁版本来使用无保证 API 的行为在当下没有坏处，但还是尽量避免为好。
对本帖而言，我觉得最合适的做法还是像你描述的这样：
2 个赞
@koishi/scripts 改变 template 文件夹的位置之后我修改 extends 路径确实是未来的负担
但是如果我现在就要自己发一个包管理 tsconfig，之后还要维护那个包的版本的话，那可就是现在和未来加起来的负担了
2 个赞
在亲身尝试之后，extends 还是有点缺陷的，除了 rootDir outDir include 要重复写一遍之外，jsx 和 jsxImportSource 也要重复写一遍
2 个赞
你自己的负担多少我不在意。开发者当下都是自己复制粘贴 tsconfig 的，你想要集中管理，理所当然应该自己承担集中管理的负担。
但你现在却想把负担推脱给他人。但愿在 scripts 改动位置后你能记得应当如何处理，而不是再来提问。
2 个赞
随便对这句话多做一点解释。如果你真的自己用，并且能够一直记得如何应对未来的更改，那么没有问题；但你却在论坛说这种做法能够使自己的负担变小。这样一来，其他开发者也会这么做，最终使更多的开发者依赖不稳定内容，从而从整体上降低 Koishi 的使用体验。哪怕你请求 Koishi 官方或者其他论坛用户来维护这个包，影响都会更小。
2 个赞
暂时消气
3 个赞
你如果真的是在为 Koishi 的维护考虑，看完上面的话，就至少应该把这个帖子隐藏，避免其他开发者看到这个帖子。
可惜你现在仍然不是在为 Koishi 考虑。你只考虑你自己。
1 个赞
你自己这么用没人管，你专门发个帖还要说「那可就是现在和未来加起来的负担了」
如果真的开源人来了肯定会考虑「如何为 Koishi 的其他开发者做点什么，改善所有人的开发体验」；你没有精力这么想可以，但你一口一个「负担」是想表达什么，这负担难道是谁造成的吗？反而是你使用不稳定内容会给原包的作者增加负担
1 个赞
我觉得如果你不是婴儿而是真的开发者的话，你至少不会说出「但是如果我现在就要自己发一个包管理……那可就是现在和未来加起来的负担了」这种话。
1 个赞
第一段几点
- Koishi 使用体验是开发者的体验还是机器人搭建者的体验还是机器人使用者的体验？
- 我谈论我自己的负担是无比正当的，你谈论开发者依赖不稳定内容和 Koishi 使用体验下降是一个假设的链条。
- 开发者完全的能且应该为自己负责，开发者可以选择依赖稳定或不稳定的内容，开发者在问题发生的时候应该自己解决。
第二段几点
- 我应该考虑我自己，这就是开源工作的方式。我不介意你讨论 Koishi 的维护或者别的想讨论的，但是那是另一个话题。
- 我有权力在公共场合谈论我自己并且对这种讨论的禁止是不恰当和对社区不健康的。
- 你为什么不发一个包来促成你希望看到的情况而是选择了花费大量笔墨来阻止你不希望看到的情况发生，在我看来二者需要的努力是差不多的。
3 个赞
是开发者的使用体验。你没有意识到你的做法会使未来开发者（包括你）的使用体验 下降，而 Koishi 现在的做法不会。
你在易语言社区购买了开发框架，然后希望有办法减少自己的负担，是正当的，开发者有义务为你解决；你在 Koishi 社区希望有办法减少自己的负担，也是正当的，但没有人有义务解决你的负担，也就没有人关心你的负担。你选择负担更重或更轻的做法不会影响到其他人，因此「降低负担」不是一件 他人 应当致力的事情。
我谈论 Koishi 使用体验下降是因为以前真的有许多开发者在开发群询问第三方框架相关问题并没能得到解答。对这些开发者而言 Koishi 的使用体验已经下降过一次了。
只有优秀的开发者能做到为自己负责，只有优秀的开发者才能在问题发生的时候自己解决问题。
那么剩下的开发者呢？当然需要求助他人或社区来解决问题。就像本帖一样。
对于优秀的开发者，其本身也不需要依靠社区解决问题，因此讨论或不讨论结果都一样。但对于剩下的，会在社区咨询和吸收意见的开发者， 社区内现有的讨论结果会影响他们的选择。 我们需要保证他们的开发体验。
作为你自己，你首先应该考虑你自己。但作为 Koishi 团队成员，你应该 同时 考虑 Koishi。这是同一个话题。如果 Koishi 团队成员不考虑 Koishi 的话，那么很难找到其他人考虑 Koishi。
你确实可以讨论你自己，但我需要讨论 Koishi。
3 楼有 Koishi 开发者已经发了一个非常优秀的包，你似乎没有采用。我想先知道你没有采用的原因。解决掉这个问题后，我们可以发个包。
1 个赞
感觉其他人会对这段话产生疑问：「为什么集中管理 tsconfig 反倒会使开发体验下降？」
我来解释一下：
一、不稳定的导出
首先，如果使用不稳定的导出，则整个项目 随时可能编译失败，也会给 scripts 包的维护者带来负担，这个上面已经讨论过了。
二、发公共包，稳定导出？
那么，发一个公共包是否就能解决这个问题？很遗憾，不行。首先，1 楼已经提到过了：这么做在 monorepo（Koishi 可行）的项目里可以使用，但在独立 repo（Koishi 推荐）方案下需要 每个插件迁移一遍，因为每个插件都要增加一个 tsconfig 所在包的 devDep。 如果没有这么做，则编译失败。
三、公共包的升级
集中管理的 tsconfig 能不能在未来新增新出的配置项？答案是 不能，除非每个依赖这个 tsconfig 包的插件都要同时升级 typescript， 否则编译失败。
因此，就算独立发包，开发者仍然会面临各种各样的编译失败，其中一些情况（比如 tsconfig 升级）的问题，开发者可能完全想不到是由于「公共包升级」导致的，因此只能再寻找社区求助。tsconfig 包的维护者只能负责解答这些重复性问题。
四、那如果公共包采用 SemVer？
还有一种做法就是给 tsconfig 升级 major，但这么做的话，一段时间后你的各个插件就会处在各个不同的 major 版本，使用不同的 tsconfig。这个问题本来是本帖想解决的问题。
实在不行，就永远不升级？
tsconfig 包永远不升级能够避免上面的「编译失败」问题。现有插件将会永远编译成功。但取而代之的是，tsconfig 将会逐渐变得陈旧，并可能无法使用 Koishi 的各种新功能。例如，JSX 就需要 tsconfig 升级来支持。如果开发者某天希望用到新功能，那么 写完新功能后就会编译失败。
结论
单论编译成功率，上述方案已经暴露出了很多缺点。
除了楼主以外，我相信很多人看到 yarn setup 每次创建的重复的 tsconfig，都会认为这样的行为不是最佳，有优化的空间，可以想办法优化。
并非如此。tsconfig 的当前行为是现时点场景下的最佳解决方案。他保证了：
- 不管多少年以后，插件都能够成功编译
- 插件能够在任何工作区，包括别人的工作区内成功编译， 从而保证 Koishi 插件的 Fork 和 PR 体验
- 插件只需要
koishi和typescript两个包就能成功编译
Koishi 的大部分设计都是经过考虑后的权衡（或者说妥协）的结果。在自己有特殊需求的情况下，完全可以考虑自己的方案，但一般情况下，为了「插件独立编译」、「PR 贡献者编译」等等特殊场景的开发体验，推荐保持 Koishi 的当前行为。
1 个赞