Definitelytyped: 为什么是 monorepo？

1. 您可以直接导航到types下的文件夹。 例如，要查看jquery ，请导航到https://github.com/DefinitelyTyped/DefinitelyTyped/tree/master/types/jquery 。
2. 您可以搜索库的名称。 例如，如果您想搜索与lodash相关的未解决问题，那么您可以访问https://github.com/DefinitelyTyped/DefinitelyTyped/issues?utf8=%E2%9C%93&q=is% 3Aissue+is%3Aopen+lodash ; 或者您可以使用搜索栏，它会将您重定向到适当的查询字符串。

这个 monorepo 不是一团糟吗？

最简单的方法是使用TypeSearch 。 您会发现这些类型是否在注册表中，如果是，则 npm 描述中的链接将准确指向它们的子文件夹。

非 monorepo 是不可能的。 通常，在一个@types包中修改某些内容的贡献者将需要修改多个下游包以修复中断或启用新功能； 这对于 GitHub 的工作流程来说绝对是一场垃圾场大火，因为没有集成的方式以原子方式合并这些 PR，同时仍然在所有这些 PR 上运行合理的 CI 构建。 如果你觉得你在看4000页的文件夹是一个问题，我们想象努力保持跨越4000个回购同步GitHub的设置。

通常，在一个@types包中修改某些内容的贡献者需要修改多个下游包以修复中断或启用新功能

我不熟悉编写@types/包，所以可能我遗漏了什么......

但这不是semver的用途吗？
与 npm 中的任何其他包相比，实现@types/包有什么特别之处？

我希望它的工作原理相同：例如，您拥有的依赖关系图。 包@types/X和使用@types/X下游包@types/Y @types/X 。 两者都由不同的人维护。 当@types/X更改时，它会以不同的版本发布，因此不会立即影响@types/Y 。 @types/Y贡献者后来决定更新到@types/X较新版本并修复由于所有重大更改引起的问题。

可能最重要的是你有DefinitelyTyped元存储库，它只维护类型存储库的链接列表。 然后是一些publisher脚本，它通过该列表并在@types/ npm-namespace 下发布所有包。

或者如果可能的话，只允许实现者直接在@types命名空间下发布。 所以我们根本不需要DefinitelyTyped元存储库。

https://github.com/npm/npm也有 2k 个问题。
https://github.com/moby/moby甚至更多。

最好的解决方案是作者维护定义，这一直受到鼓励。

@franklinyu问题的数量不是问题所在。 考虑到这个 repo 聚合了 >4k 类型，大量的问题是可以的。

真正的问题是： DefinitelyTyped试图通过在一个 repo 中聚合所有类型来解决什么问题？

不幸的是，semver 不能很好地用于打字包。 类型包的major.minor版本需要与 javascript 包的major.minor匹配，否则人们将不知道为任何给定的 javascript 包版本使用哪个@types版本。

例如，现在如果您安装[email protected] ，那么您还将安装@types/[email protected] （现在它位于4.14.109 ）。 但是，想象一下lodash类型中有一个错误（相信我，这种情况经常发生），并且有人修复了它。 现在我们把版本号改成什么？ 根据定义，对类型定义的任何更改都是接口破坏性更改（或至少是接口添加）。 但是我们不能将版本提高到4.15.0因为这些类型是用于4.14 ，而不是4.15 。 我们当然不想将版本号增加到5.0.0 。 因此，我们将版本号改为4.14.110 ，即使界面发生了变化，因为实际上旧界面只是不准确。

@ AJ-R确定， major.minor的版本@type/X应等于major.minor的版本X ，并且如果存在一个错误@type/X你使用patch版本来修复它。 听起来不错。

这与原始问题有什么关系：monorepo 与单独的 repos？

抱歉，我应该很清楚 - 我正在解决您之前的评论之一：

但这不是 _semver_ 的用途吗？

通过在一个存储库中聚合所有类型，DefinitelyTyped 试图解决什么问题？

将 DT 拆分为 4,000 个单独的 GitHub 存储库要解决什么

每天都有一个 TypeScript 团队成员管理 PR 积压，合并或审查几十个 PR。 机器人会密切关注我们获得的大量 PR。 我们运行 repo-wide lint 规则来捕获常见错误，我们会定期打开新的 lint 规则，因为我们认为有帮助。 我们找到并修复被未来编译器版本破坏的定义。

将其拆分为数千个子存储库会使所有这些变得更加困难，并且不会使其他任何事情变得更容易。 那我们为什么要这样做呢？

将 DT 拆分为 4,000 个单独的 GitHub 存储库要解决什么问题？

1. 作为用户，您可以更快地找到资源。 您不必使用诸如 TypeSearch 之类的其他应用程序来访问资源。 在 npm 上，您可以直接链接到所需的输入库。

2. 作为用户，可以更轻松地查看当前问题并提交新问题。

   • 您不必搜索和过滤一个具有 > 2k 问题的大型存储库。 如果记者忘记遵循问题命名规则（即[@types/name-of-package] Issue description ）怎么办？ 你永远找不到需要的问题。
   • 因此，提交重复文件的可能性较小。

3. 作为贡献者，您可以清楚地监控您的存储库中有多少问题。

   • 您不必（再次）过滤任何内容来获取具体打字的问题。 不太可能错过所需的问题。
   • 您有明确的动机将问题数量保持在较低水平。 问题编号不再是共同责任。
   • 因此，忘记多年来悬而未决的问题的可能性较小。
     例如。 2013 年有 1 个问题页面，2014 年有 5 个问题页面，依此类推。

4. 作为 TypeScript 团队成员，您将更多时间用于改进 typescript 本身（例如 jsdoc 支持），而不是维护/合并/审查大量 npm 包的数千种类型。
   在成熟的生态系统中，这是社区应该做的。

   • 我们运行 repo-wide lint 规则来捕获常见错误

     发布带有所有推荐规则的 lint 预设，并建议所有贡献者使用该预设的最新版本。

   • 我们找到并修复被未来编译器版本破坏的定义。

     这就是社区贡献者应该做的。 预期的ts-compiler 版本应该在typing-package 的package.json的peerDependency部分中明确说明，因此当您在错误的环境中使用它时，它会警告您。

您是从打字实际上由任何人拥有的心态来解决这个问题的。 现实情况是，这个 repo 中的绝大多数文件是由运行 dts-gen 的人编写的，并进行了一些修复，然后由其他三个人每年修改一次。 这里没有强大的所有权模型，也不需要。

当这些存储库之一的临时自称“所有者”决定停止维护它时会发生什么？ 这一切发生

对于想要提交修复程序的人来说，这也只会让生活变得更糟。 去年我们在 React 定义文件中添加了一个类型参数，需要在数百个文件中进行下游更改。 有没有人想要克隆数百个存储库（哦，哪个存储库？）来进行广泛的更改，然后管理数百个并发拉取请求？ 甚至在任何地方都没有用于此的工具。

作为 TypeScript 团队成员，您将更多时间用于改进 typescript 本身（例如 jsdoc 支持），而不是维护/合并/审查大量 npm 包的数千种类型。 在成熟的生态系统中，这是社区应该做的。

我们确实尝试过这个，但它没有用。 DT 完全是社区驱动的，它导致了数百个拉取请求积压。 从那时起，合并 PR 的平均时间从 2 周减少到 4 天（这是有意的最小值，因此人们有时间权衡变化），尽管 PR 数量从~200/月减少到~1,000/月.

好的，我想我对我原来的问题“为什么是 monorepo？”有了答案：
因为 TypeScript 团队更容易维护类型定义（考虑类型依赖、下游包的原子更新、CI、linting 等）

我仍然认为 TypeScript 团队在主要由自己维护数千个包中扮演如此重要角色的模型有点奇怪。 特别是在模块化、社区驱动的 npm 世界中。

但如果这个模型适合你。 然后好了 :smiley:

@art-in 我不相信目的是管理这个 repo 中的所有类型，而是管理包本身不提供的类型。 如果一个包想要为它的包发布类型，它可以直接在包中发布。 absoluteTyped 只是一个无需原始包维护者同意即可聚合类型的地方。