<p>TypeScript 4.0 迭代计划</p>

您是否考虑在 4.0 中包含https://github.com/microsoft/TypeScript/pull/29818可能在实验标志后面？

由于工厂函数定义本身的变化，这变得复杂了。

不过，引入一个_separate_工厂虚拟类型定义可能会很有趣； 比如说JSX.Factory或React.JSX.Factory ，TypeScript 然后可以将其用于推理。 我不太确定仅将 JSX 语法转换为函数调用是否足够或有效，但由于它是一种虚拟类型，它不必对应于任何具体的 JavaScript 实体。 当然，风险正在进入与我们现在相同的情况，一堆虚拟类型最终限制了类型安全，不仅是儿童，而且是 React 15 之后引入的几个特性。

你会考虑在 4.0 中也包含https://github.com/microsoft/TypeScript/pull/24738吗？

看到没有提及 #33038 [👍 140 和您自己的实际公关@weswigham] 或 #202 [👍 390] 有点难过，而像 #15230 [👍 27] 这样的门票被认为是“高需求”。 我意识到你不能真正根据“喜欢”来比较或优先考虑，但如果有一些路线图更新会很棒，尤其是 4.0 似乎是引入这样一个功能的好机会。 🙏

约 3.5 年的问题等待反馈，有近 200 条评论 #13778 为数组解构等内容提供了不准确的类型。 Pwetty pwease 我们可以实施修复吗？

我很欣赏人们偶尔会提出他们认为需要关注路线图和迭代计划的问题，但我认为我需要在这里明确一点——“调查高需求错误修复”部分是通过查看明显导致大量问题的问题来确定的剪纸，但范围似乎合理。 我们肯定仍然注意提到的问题，但其中一些问题没有那么大，也没有明确的理想结果。

例子：

• 名义品牌会很好，但这会与未来围绕名义的语言方向组成吗？ 作为提议者，我什至担心占位符类型。
• 索引签名上的undefined是一个有趣的例子，但我们不想添加让 90% 已经在当前假设下操作的人更难的行为。 找到一种组合并允许用户逐步采用这些检查的方法对我们来说并不是显而易见的事情。 即使使用一堆条件类型和特殊的编译器检查在技术上是可行的，但这些解决方案往往非常明显很笨拙并且很快就会崩溃。

名义品牌会很好，但这会与未来围绕名义的语言方向组成吗？

@DanielRosenwasser您认为未来的语言方向是什么？

我想我会给出一些关于我的思想在名义上的背景。 当人们询问名义类型时，会有很多不同的想法，包括

• “传统的”基于声明的名词性（例如，您在大多数 OO 语言中看到的）
• 不透明类型（其内容在外部完全未知的类型）
• 不同的别名（C/C++/C# 中的单个成员struct newtype ，Kotlin 中的内联类）
• 度量单位（一种将维度分析编码到语言中的方法）

其中一些之间存在阴影（例如占位符类型声明- 一种回落到实现类型的不透明类型的变体），然后有不同的方向将这些中的每一个混合在一起。

@RyanCavanaugh对此做了一个很好的类比，其中 3 个孩子向父母要一只宠物。 一个人要狗，一个人要猫，一个人要鱼。 他们问他们的父母“我们什么时候养宠物！？” 显然他们都同意他们想要一只宠物，但每个人都想要一只不同的宠物！

我喜欢品牌类型吗？ 我做！ 品牌类型实现了类似不同别名的功能，并且符合大多数用户的需求。 但我认为这不是正确的思考方式。 有更多的设计空间需要通过大量已知的权衡来充实，没有什么让我觉得我们需要尽快找到解决方案。

我想我们是否可以将https://github.com/microsoft/TSJS-lib-generator/pull/858导入TypeScript 4.0 。

@DanielRosenwasser首先感谢您的写作🙇

您能否详细说明一下标称类型实际适用于 TypeScript 的用例？

第一：请随时将我发送到巨大的文字墙或仓库，我会阅读它：]

我不是指像占位符类型这样的不透明类型——我指的是你所谓的“传统”名义类型。

我一直觉得名义类型与 JavaScript 是对立的，这就是为什么以前的尝试并没有真正奏效的原因。 有一些方法可以让它很好地工作（swift中的协议和haskell中的类型类被认为是“名义上但可以从外部扩展”），我相信你熟悉大多数“成熟”的方式（我假设“计量单位”是 F# 眨眼）。

我发现很多人要求提供名义（如“传统”）类型，但没有很多关于_why_的文章。

随着时间的推移，我们看到越来越少的人要求使用“传统”的名义类型，这可能是因为社区共同为结构类型建立了一种心理模式。 在某些地方，类型确实在名义上起作用（当涉及instanceof或存在私有时）。 其中一些是通过更好的控制流分析和兼容性检查来捕获的，但它并不完美。

一些“传统”用例与零开销名义包装器类型（例如newtype ）的用例相同，并且很多时候旨在确保对文件等内容进行特殊处理路径、不受信任的字符串等。

我感觉 Typescript 已经足够表达了。 我个人希望看到的是更好的工具集成。

• 支持 ESM https://github.com/microsoft/TypeScript/pull/35148 https://github.com/microsoft/TypeScript/issues/16577
• 编译器插件https://github.com/microsoft/TypeScript/issues/16607 https://github.com/microsoft/TypeScript/issues/38736
• 纱线 pnp https://github.com/microsoft/TypeScript/issues/28289 https://github.com/microsoft/TypeScript/pull/35206

由于上述原因，通常会看到笨拙和笨拙的解决方案。 大多数 react 项目都包含 babel 用于 react-hot-loader（编译器插件），一些 CSS 系统还需要 babel 进行编译时转换。 使用 pnp、esm 甚至 CSS 模块需要更多工具和解决方法来解决 tsc 限制。

同样令人沮丧的是，对于其中一些问题，社区以 PR 或提案的形式提出了具体的解决方案，但这些都被拒绝或搁置多年。 作为从业者，在更广泛的生态系统中使用 TS 变得越来越难。

无论如何，我只是来自互联网的随机人。

@DanielRosenwasser也许https://github.com/microsoft/TypeScript/pull/29374可以及时得到 4.0 的审查？ 我认为它涵盖了人们倾向于询问的this -before- super案例中的许多（大多数？）。

请重新考虑是否支持使用包含文件扩展名的文件路径引用 ES 模块。 它将大大推动多环境代码的公平竞争。

https://github.com/microsoft/TypeScript/issues/16577

感谢您关注 typescript 的工具！ 我希望您可以考虑提供与https://github.com/microsoft/tsdoc 的更紧密集成。 许多其他现代语言，如 go 和 rust 提供开箱即用的文档工具，并鼓励开发人员编写标准注释，但 typescript 在这方面缺乏。

如果 #31445 可以被选中，那就太好了，这对我们来说是一个交易破坏者，我相信很多人（基于该问题有多少引用）！

可以https://github.com/microsoft/TypeScript/pull/38967包含在TypeScript 4.0中，也可以包含在https://github.com/microsoft/TypeScript/pull/35608中。

我发现人们要求将所有内容都包含在 4.0 版本中😆

感觉 TS 正在失去动力？ 下一个 _major_ 4.0.0 版本的无效合并和短路分配？ 不再有远大的目标和抱负的想法了吗？

对于下一个专业，我希望：

• 更高种类的打字
• 依赖类型？ 类型级函数？ （好的，这个可以用于5.0.0）
• 标称类型
• 宏指令
• 支持tsconfig.json中的转换器
• 编译为 WASM（某些语言子集）

@canonic-epicure 同意，目前感觉下一个版本更像是 3.10

感觉 TS 正在失去动力？ 下一个主要版本 4.0.0 的无效合并和短路分配？ 不再有远大的目标和抱负的想法了吗？

TypeScript 不遵循 semver。 没有 v0.10、v1.10、v2.10 或 v3.10。 所以这实际上是一个正常的里程碑。 有点奇怪，人们期待 4.0 有如此多的变化，但在 3.9 或之前的迭代计划中却什么也没说。 🙈

类型级函数

type X<T> = T可以在某种程度上做到这一点。 （不支持高阶函数。）

宏指令

IMO 它不满足 Typescript 的目标。

支持 tsconfig.json 中的转换器

试一试： https ://github.com/cevek/ttypescript

编译为 WASM（某些语言子集）

你在寻找https://www.assemblyscript.org/

好的，所以 4.0.0 只是下一个小版本，很高兴知道。

关于“宏不满足 TS 目标”和“对变形金刚使用 ttypescript”（顺便说一句， ts-patch效果更好）——这类似于绝地武士——“这不是你需要的功能”。 不，请开箱即用的宏和变压器。 它是几年前要求的。

我也想在 TypeScript 中使用 marco，但反对这一点的理由很多。

1. 如果 Marco 可以生成不同的 JavaScript 代码，那么它就是在创建一种新的非类型级别的语法，因此它是对 ES 规范的扩展。 enum 、 import x = require(...) 、 module是这个规则的例外，但它们来自 TypeScript 的早期。

2. 如果你想用Marco跨不同的文件生成不同的JS文件，那么就不可能傻掉所有类型的语法来获取JavaScript文件。

3. Marcos 可以增加分析和编译时间，并且很可能被滥用。

4. 如果 Marco 可以根据类型信息发出不同的 JS 文件，这将使 Babel 无法处理这种语法。 所以这种行为违反了isolatedModules规则（例外： const enum和module ）

5. 如果 Marco 只能做一个“类型级别的 Marco”并且可以被 Babel 安全地擦除，它就变得毫无用处，但对于高阶/编程类型仍然有用。 因此它没有违反任何目标，但我怀疑 TypeScript 团队是否会对这个想法感兴趣。 （我在 https://github.com/Jack-Works/typescript-marco-demo/blob/master/marco-test.ts 做了一个演示）。

@Jack-Works 我不明白你的观点。 也许您的意思是宏将扩展解析器并创建新的语法？

对我来说，宏只是 AST -> AST 函数，它以某种方式运行先前的类型检查器，因此它可以创建新的 AST 节点，这些节点将定期进行类型检查。 然而，它不会创建新的语法——输入是常规的 AST，输出也是。 它确实在 AST 中创建了新节点。

讨论将与该线程无关，也许将在不和谐的#compiler 频道上继续？

#38597 可以包含在 TypeScript 4.0 中吗？

@DanielRosenwasser

索引签名上的未定义是一个有趣的例子，但我们不想添加让 90% 已经在当前假设下操作的人更难的行为。

只是好奇你怎么知道它是 90% 的人？

@wongjiahau这个号码是随便编的，方便解释。 不确定这是否是您要问的具体问题。

提醒大家：我们的团队不会在 6 月 19 日工作，所以我们会稍微推迟一下时间表。 测试版现在定于 6 月 25 日下周四发货。

@DanielRosenwasser我试图指出您正在使用一些虚构的任意数字来否认该功能（#13778）的重要性，该功能显然符合 Typescript 的第一个目标，即静态识别可能的构造是错误的。

请不要误会我的意思，我感谢核心团队为这个项目付出的辛勤工作，但我只是认为如果我们能够真正与这个项目的目标保持一致，我们可以做得更好允许未经证实的陈述阻碍其进步。

@wongjiahau我们没有参加会议并说“丹尼尔说这个数字是 90%，这超过了我们 85% 的阈值，我们永远不要做这个功能”。 我们仍在调查它，我们非常了解开发人员对它的需求，但我们也在实践中测试了这个功能的样子，我可以告诉你它并不漂亮。

如果你要像这样过度分析我们这样的陈述，你只会从我们那里得到更少的陈述，因为我们有更好的事情要做，而不是在互联网上被积极误解。

4.0 绝对是一个里程碑，而不是“3.9 的下一个版本”。

@typescript-bot 创建 release-4.0

嘿@DanielRosenwasser ，我已经开始为你创建release-4.0分支。 这是我对日志的最佳猜测的链接。

@Kingwl如果这是里程碑，那么那些大事是什么，或者至少是什么英雄功能？ 我在本期顶部的语言功能列表中没有看到任何如此棒的东西。 与大多数 3.x 版本相比，没有什么不寻常的。
当然你可能会说它只是需要发布主要版本的破坏性更改，但很难称其为“里程碑”。

@wgebczyk在我看来，带有标记元组元素的可变元组是里程碑。

@wgebczyk没关系。 但实际上 Variadic Tuples 是。

@xiaoxiangmoe @Kingwl 里程碑？ 英寸石。

它在那里： https: //devblogs.microsoft.com/typescript/announcing-typescript-4-0-beta/#variadic -tuple-types
什么时候能达到稳定版？ 我迫不及待地想在 VS Code 的日常编码中应用它。

@mk0y根据 8 月 18 日的开幕消息。

@wgebczyk我们的发布是基于时间的； 每个版本都包含大约三个月的团队工作。 我们的里程碑版本控制政策 (n = n + 0.1) 在过去的 20 个版本中一直是一致的，所以希望这不会在某个时候让人们感到惊讶😅

您会考虑在下一个次要版本中允许symbol类型进行索引吗？ 你能实现并合并拉取请求 26797吗？

嘿@DanielRosenwasser ，我已经开始为您将release-4.0上的版本号更新为4.0.1-rc 。 这是我对日志的最佳猜测的链接。

@typescript-bot 同步 release-4.0

嘿， @DanielRosenwasser ，我已经开始为你同步release-4.0与 master。 这是我对日志的最佳猜测的链接。

@typescript-bot 同步 release-4.0

嘿， @DanielRosenwasser ，我已经开始为你同步release-4.0与 master。 这是我对日志的最佳猜测的链接。

@weswigham mmmmmmmmmmmmmmmmmmmm ，机器人讨厌我）：）：）：）：

绝对不急，但我手动完成并提交了此文件： https ://github.com/microsoft/TypeScript/issues/39869

某个地方是否已经有 4.0 之后的路线图？ 我想提高#37582，因为需求越来越大（#39965、#38149、#27481、#39965、#38546）。 对我来说，这似乎是一个范围合理的问题。

作为更新，我们必须将 RC 提前 2 天才能启动网站，并且对于我们认为需要登陆 RC 的其他更改。 我们预计不会有任何事情将我们推得更远，但为了安全起见，我们将再给自己 2 天的时间来获得有关 RC 的反馈，并将目标改为第 20 天。

@typescript-bot 凹凸版本-4.0

嘿@DanielRosenwasser ，我已经开始为您将release-4.0上的版本号更新为4.0.2 。 这是我对日志的最佳猜测的链接。

现在是 8 月 20 日 :)

嘿嘿，现在还是8月19日，还有20分钟，我想你还得再等一会儿。 如果您不能再花一分钟，我们会在 npm 上发布每晚版本！ 😄

等待发布，已经在 npm 中发布了 :)

@typescript-bot 凹凸版本-4.0

嘿@DanielRosenwasser ，我已经开始为您将release-4.0上的版本号更新为4.0.3 。 这是我对日志的最佳猜测的链接。

@typescript-bot 凹凸版本-4.1

嘿@DanielRosenwasser ，我已经开始为您将release-4.1上的版本号更新为4.1.1-rc 。 这是我对日志的最佳猜测的链接。

不好了

@typescript-bot 凹凸版本-4.0

嘿@DanielRosenwasser ，我已经开始为您将release-4.0上的版本号更新为4.0.4 。 这是我对日志的最佳猜测的链接。

@typescript-bot 凹凸版本-4.0

嘿@DanielRosenwasser ，我已经开始为您将release-4.0上的版本号更新为4.0.5 。 这是我对日志的最佳猜测的链接。