Definitelytyped: META - 更新最低 TypeScript 版本

unknown是什么时候添加的？ 要么做大，要么回家！ 到目前为止，DT 中的所有any都是这些部分中“打字稿应该抓住它”错误的最大来源。

unknown是什么时候添加的？

3.0

你。 所以，99.9%！

我同意我们应该这样做。 我们开工吧！

请问，你能不能慢慢增加它？ 2.1 一个月，2.2 下个月，等等？

每个版本都有一些小的重大变化。 一开始慢慢有条不紊地进行，会更容易理解这会带来什么麻烦。

处于维护模式的项目通常没有足够的带宽来克服这些重大变化，尤其是当它们是基础架构的核心时。

是的，特别是node类型因缺乏新功能而受到影响，并且不得不使用许多 ~hacks~ 变通方法。

@JoshuaKGoldberg处于维护模式的项目不太可能逐月升级类型定义的版本，是吗？

@JoshuaKGoldberg确实记得升级 DT 不会删除已经发布到 npm 的历史类型定义。 @types历史版本就像 Mumm-Ra 一样永远存在。

无论 DT 在哪里进行版本控制，您都可以依赖这些。

说得通

嗨@RyanCavanaugh ，
我100%支持这样的想法。 TypeScript v2.0 阻止了许多包的更好类型系统，包括node 。
我关心社区和企业的透明度和可预测性。 有问题：

• 你认为什么时候是更改最低支持的 TypeScript 版本的好时机？ 在发布 TS 3.7 期间？
• 如果我错了，请纠正我，但这看起来像是 2.8 之前的 TypeScript 版本的生命终结？
• 我们可以有类似于Node.js的时间表吗？ 此类文档将帮助开发团队推动业务批准开发资源进行更新。

有什么理由为什么它是 2.8 而不是不同的版本？ （例如 3.0 代表unknown 。）

2.8 是引入条件类型的时候

非常赞成。

请考虑建立一个（半）正式的时间表，以便社区可以依靠随着时间的推移可预测地增加的最低版本。 比如：“每年 11 月，我们计划将最低 typescript 版本更新为 18 个月前的版本。请相应地计划。”

@donaldpipowitch
在 3.0 之前的用户中，我们看到一群人仍在使用 2.8。 （当然，正如@IllusionMH指出的那样，条件类型使 2.8 成为 DT 类型的流行目标。）

我们希望定期重新审视这个问题，因为我们希望人们继续升级。

@galkin
从技术上讲，旧版本的 Typescript 根本不提供服务，而这个变化是从 Definitive Typed 停止服务。 当然旧版本的 Typescript 可以继续获取现有版本的 DT 包。 他们只是不会得到更新。

但是，这只是技术性问题。 对我们来说，制作一个类似 LTS 的时间表是个好主意。 不过，我们还没有开始这样做。 在这种情况下，数据足够清晰，可以轻松做出事后决策。 我还不确定如何预测未来弃用的好日期。

回复：日期：无论如何，我必须更新 3.7 的 DT 基础架构，所以它将在 3.7 的发布日作为发布的一部分进行。

对我们来说，制作一个类似 LTS 的时间表是个好主意。

只是想回应一下，我认为这种时间表是一个非常可靠的想法。

@johnnyreilly我们正在寻找微软的先例。 不过，没有什么比绝对打字更好的了！

@RyanCavanaugh ，有什么更新吗？

@galkin如果您有建议的弃用时间表，请将其发布到此线程以便我们讨论。

@sandersn ，这是我对这个问题的看法

• 我们是否需要 TypeScript 版本的生命周期终止 (EOL)？
  当然，是的。 支持每一个创建的 TypeScript 版本都需要额外的资源。
• 为什么我们应该有 EOL 时间表？
  _最好的做法是提前明确您的项目状态。 如果你不再支持一个项目，或者你正在结束它，那么让任何偶然发现你的代码的人都痛苦地明白这一点_ (c) Jared Smith。
• 应该使用什么作为时间表的基础？
  分析？ 基于分析的每一个决定都是妥协。 每一个这样的决定都是对我们将取笑社区/业务的哪一部分的问题的回答。 WordPress 有类似的问题，他们应该支持什么最小版本的 WP/PHP/MySQL 。 这是危险的方式。
  依赖工具计划？ 视觉代码/Microsoft Azure/Angular/等。 太多的选择，太容易开始新的圣战。
  TC39 流程？ 不错的选择，但 TC39 不会也不会为任何语言功能引入 EoL。
  节点.js？ Node.js 是 JS 社区的驱动程序，具有发布/EOL 时间表。 TypeScript 使用 Node.js。 我认为这是时间表的最佳基础。
• 如何创建时间表？
  选项 1.将 TypeScript 版本与 Node.js 版本相关联，并宣布类似的 EOL。 比如 2 年前Node.js v8 启动 LTS ， TypeScript v2.6 发布，所以 2019.12.31 是 EOL。
  选项 2 Node.js 在 EOL 之前有 12 + 18 个月的政策。 我们可以使用相同的方法，2.5 年。 它可能太长，但不能少于 2 年。
  选项 3与决策者开会并与社区分享结果

所以我的建议看起来像这样：

版本 | 发布 | 2.5 年后寿命终止 | 2 年内结束生命
-- | -- | -- | --
2.1 | 2016 年 12 月 | 2019 年 6 月 | 2018 年 12 月
2.2 | 2017 年 2 月 | 2019 年 8 月 | 2019 年 2 月
2.3 | 2017 年 4 月 | 2019 年 9 月 | 2019 年 4 月
2.4 | 2017 年 6 月 | 2019 年 11 月 | 2019 年 6 月
2.5 | 2017 年 8 月 | 2020 年 1 月 | 2019 年 8 月
2.6 | 2017 年 10 月 | 2020 年 3 月 | 2019 年 10 月
2.7 | 2018 年 1 月 | 2020 年 7 月 | 2020 年 1 月
2.8 | 2018 年 3 月 | 2020 年 8 月 | 2020 年 2 月
2.9 | 2018 年 5 月 | 2020 年 10 月 | 2020 年 4 月
3 | 2018 年 7 月 | 2020 年 12 月 | 2020 年 6 月
3.1 | 2018 年 9 月 | 2021 年 3 月 | 2020 年 8 月
3.2 | 2018 年 11 月 | 2021 年 5 月 | 2020 年 10 月
3.3 | 2019 年 1 月 | 2021 年 7 月 | 2020 年 12 月
3.4 | 2019 年 3 月 | 2021 年 8 月 | 2021 年 2 月
3.5 | 2019 年 5 月 | 2021 年 10 月 | 2021 年 4 月
3.6 | 2019 年 8 月 | 2022 年 1 月 | 2021 年 7 月
3.7 | 2019 年 11 月 | 2022 年 5 月 | 2021 年 10 月

哇，这太棒了！ 感谢您对此的想法。

几个小点：

1. Typed 和 Typescript 绝对是不同的项目，尽管它们应该具有相同的 EOL 时间表。
2. 上面列出了 EOL 对 DT 的含义，但对 TS 来说不是很清楚。 据我所知，我们创建的补丁版本从未超过一个次要版本。 另一方面，我们没有向人们推荐更新版本的 TS，除非作为一般的良好做法或特定的解决方法。
3. 由于 TS 作为 Visual Studio 的一部分发布，这是一个带有支持合同的付费产品，我们可能必须定义一个特定于 VS 的扩展来定义任何开源支持期。 不过，这不应该影响开源社区。

@DanielRosenwasser你介意有空的时候看看这个吗？

2.8 现在是新的最小值。 2.0 - 2.7 将不再进行测试，并且 ts2.0 - ts2.7 标签将不再在现有的@types/*包上更新。 安装@types/*@latest的 2.8 之前的用户可能会得到不适合他们的类型。

我不打算结束这个问题，因为正在进行讨论（而且这是一个元问题？）。

@sandersn这是否意味着通常验证依赖项是否具有更大或相等的检查（例如，任意包（x > 1 的 2.x 引用 x = 1 的另一个包）版本现在被禁用？

询问是因为这是向前移动节点类型的主要障碍。

@SimonSchick不，它没有被禁用； 它仅适用于需要>=2.8的标头。

换句话说，您不能将@types/node更新为需要 3.1，因为有很多包指定 2.8 或 2.4 —— 这被视为 2.8。 但是你现在绝对可以让@types/node要求 2.8。 这意味着您可以使用条件类型，并且您可以假设 2.8+ 语义适用于它们与旧版本不同的地方。

实际上，默认值为 2.8，因此在标头中根本没有要求的版本就相当于要求 2.8。

@sandersn ，我们可以谈谈最小版本的新更新吗？ 我认为这是一个好时机，因为 3.8 发布了。

我们一直在内部讨论它，并倾向于支持节点式的 30 个月时间表。 但我需要与 Typescript-VS 集成团队协调，他们希望有一个支持 new-TS-in-old-VS 的时间表，所以我还没有尝试重新开始讨论； 如果我们最终有 30 个月，下一次弃用将在 8 月，所以我们有一点时间。

更新：我与 VS 上的 Typescript-Javascript 团队进行了交谈，他们决定了 2 年或 2.5 年的时间表。 他们将收集一些使用数据来帮助他们在两者之间做出决定。 我也让他们的方案倒退了——它支持 old-TS-in-new-VS。

根据我们之前收集的使用数据 [1]，我更喜欢 2 年的窗口，只是为了减少维护负担。 它还可以让重要的软件包提前 6 个月开始使用新功能，而无需更新家属。 到目前为止，短暂的支持窗口没有我所看到的实际缺点。

然而，node 的时间表可能会让人们期待一个 2.5 年的窗口。 更长的窗口还有其他优点吗？ 我缺少的缺点？

[1]
以上数据转载：

• 遥测表明 99.9% 的 VS Code 用户是 3.0 或更高版本
• 遥测表明 97% 的 VS 用户使用 3.0 或更高版本
• 20% 的 DT 软件包已经选择加入 2.8 或更新版本

我喜欢较短的窗口； 既是为了减少维护负担，又是考虑到您发现@sandersn 的数据。

感谢更新！

也适用于较短的窗口。

一个长窗口只会让那些只更新部分依赖项而不是打字稿的人受益，而且这应该只是一个很小的群体。
大多数时候，人们要么定期更新所有依赖项（包括 typescript），要么根本不更新。
或者反过来：大多数两年内没有更新 TypeScript 的开发人员可能根本不关心新的包和新的类型定义。
因此，这可能会比您想象的要少得多，而且它会阻止整个生态系统的发展。

TL;博士; @sandersn ，你觉得 18 个月怎么样？

我的想法：

我写

选项 2 Node.js 在 EOL 之前有 12 + 18 个月的政策。 我们可以使用相同的方法，2.5 年。 它可能太长，但不能少于 2 年。

但我不记得为什么我认为 2 年是正确的时间段。 我无法从逻辑上证实这 2 年。 现在，重新考虑一下，在我看来应该有..., but not less 18 months 。

LTS 计划涵盖的每个主要版本都将在其进入 LTS 覆盖范围之日起积极维护 12 个月。 在这 12 个月的积极支持之后，主要版本将过渡到“维护”模式额外 18 个月。 在 Node.js 12 之前，活跃期为 18 个月，维护期为 12 个月。 (c) Node.js 发布计划

动机：每个 TypeScipt 版本首先作为 rc/beta 发布。 因此，每个稳定版本从第一天起都有维护模式，18 个月就足够了。

这是合乎逻辑的。 但是，如果我们使用 18 个月作为窗口，我们将在 2020 年 3 月弃用 3.1。鉴于我们的遥测显示仍有大量 VS 用户仍在使用 3.1，我认为不应该弃用 3.1。

但是，自 10 月底以来，这些数字可能会发生变化。 我会找出他们目前的情况。

自 10 月底以来，VS 中 3.1 的使用量并没有下降太多。 有趣的是，95%的使用都集中在3.9-3.4。

我认为 3.1 仍然使用了这么多，因为 VS 会让你在下载更新时避免更新 typescript，但我不确定。 无论如何，这种行为可能会在未来的 VS 版本以及其他不经常更新的 IDE 中继续存在。

综上所述，要支持 98% 的 VS 用户，我们需要一个 2 年的窗口。 要支持 95%，我们只需要 1 年的窗口！ 但是在两者之间没有什么意义。

根据该数据，我仍然支持 2 年。

在我看来，这里的讨论已经结束。 我将选择 2 年的支持窗口。

2.8 于 2018 年 3 月 27 日发布，所以我不会立即删除支持。 但我会在接下来的几周内这样做，完成后我会更新并关闭这个问题。

我有一个 PR，它在 #42834 处将文档添加到 README 中。

我在 #42881 将文档更改翻译成俄语

有人可以帮助将翻译更改为：

• 自述文件.cn.md
• 自述文件.es.md
• 自述文件.ko.md

@kingwl @armanio123 @saschanaz是我所知道的参与度最高的打字员，他们是这三种语言的母语使用者。

（当然如果你太忙，可以忽略这个。）

任务是否为#42834 中的更改添加翻译？

我在 #42818 将文档更改翻译成俄语

它是#42881 😁

是的。

任务是否为#42834 中的更改添加翻译？

我在 #42818 将文档更改翻译成俄语

它是#42881 😁

固定的。 对不起，我打错了。

更新：在发布 3.9 的同时，我刚刚删除了对 2.8 的支持。

我推迟了弃用有两个原因。

1 一般 covid-19 延迟。

1. 我们正在将 types-publisher 基础架构切换到发布到命名空间@definitelytyped/*的 monorepo 中。 版本更新现在是该 monorepo 的一部分。 不幸的是，我们仍在等待 MS 开源办公室将 monorepo 开源，但应该很快。

尽管 4.0 版本不会在 5 月发布，但我仍会按计划在 5 月取消对 2.9 的支持。 使用新设置应该会容易一些。