原副标题：TypeScript 5.1 正式发布！
（责任编辑写作天数：16两分钟)
责任编辑译者：Daniel Rosenwasser
那时，他们很开心地正式宣布 Type 5.1 正式发布！
Type 是一类透过加进称作“类别”（Type）的内部结构构筑在 Java 其内的词汇。那些类别能叙述相关流程的许多技术细节，因此能在校对以后由 Type 检查和，捕捉可能将的错字、方法论严重错误等。Type 还采用那些类别来提供更多GUI工具，如标识符顺利完成、解构等。实际上，假如您早已在 Visual Studio 或 VS Code 等GUI中撰写 Java，所以 Type 早已为此种新体验提供更多了全力支持！您能在 https://typelang.org/ 介绍更多重要信息。
npminstall -D type这是 Type 5.1 中新功能的条目：
enum回到表达式的显式回到更单纯 getter 和 setter 的不相关类别 JSX 原素和 JSX 条码类别间的解耦类别检查和 重新命名内部空间 JSX 特性 typeRoots 在组件导出中被查阅 JSX 条码的镜像滑鼠 @param JSDoc 条码的短片顺利完成 ……自 Beta 和 RC 年来有甚么新功能？
好景不长 beta 版年来，他们早已纠偏了点缀器中 init 挂勾的许多犯罪行为，即使提议的犯罪行为早已修正过。除此之外，他们还更动了在 isolatedModules 下的升空犯罪行为，保证脚责任编辑件不能被重写出组件。这也意味著采用 transpileModule API 时将保证脚责任编辑件不能被说明成组件，即使它假定采用了 isolatedModules。
自 RC 版年来，他们对内置进行了轻微迭代，并将声明移至现有文档中。但是他们认为实施仍需要许多改进。因此您目前可能将无法在大多数GUI中访问它，因此只能透过采用 Type 的夜间版才能选择加入该功能。预计 Type 5.2 或 Type 5.1 未来补丁版将重新引入此解构。
enum回到表达式的显式回到更单纯
在 Java 中，假如一个表达式在没有回到的情况下结束运行，它会回到值 undefined。
functionfoo( ) { // no return }// x = undefinedletx = foo;
然而，在以前的 Type 版中，唯一能完全没有 return 语句的表达式是 void- 和 any-returning 表达式。这意味著即使你明确地说“这个表达式回到enum”，你也被迫至少有一个回到语句。
// ✅ fine – we inferred that f1 returns voidfunctionf1( ) { // no returns}// ✅ fine – void doesnt need a return statementfunctionf2( ): void{ // no returns}
// ✅ fine – any doesnt need a return statementfunctionf3( ): any{ // no returns}
// ❌ error!// A function whose declared type is neither void nor any must return a value.functionf4( ): undefined{ // no returns}
假如某些 API 期望表达式回到 undefined，这可能将会很痛苦，您将需要至少有一个显式回到 undefined 或一个 return 语句和一个显式注释。
declarefunctiontakesFunction( f: => undefined): undefined;// ❌ error!// Argument of type => void is not assignable to parameter of type => undefined.takesFunction(=> { // no returns});
// ❌ error!// A function whose declared type is neither void nor any must return a value.takesFunction(: undefined=> { // no returns});
// ❌ error!// Argument of type => void is not assignable to parameter of type => undefined.takesFunction( => { return; });
// ✅ workstakesFunction( => { returnundefined; });
// ✅ workstakesFunction(: undefined=> { return; });
此种犯罪行为令人沮丧和困惑，尤其是在调用不受控制的表达式时。理解推断 void over undefined 间的相互作用，undefined-returning 表达式是否需要 return 语句等间的相互作用似乎会让人分心。
首先，Type 5.1 现在允许回到enum的函数没有 return 语句。
// ✅ Works in Type 5.1!functionf4( ): undefined{ // no returns}// ✅ Works in Type 5.1!takesFunction(:undefined=> { // no returns});
其次，假如表达式没有回到表达式因此被传递给期望回到 undefined 的表达式，Type 会推断该表达式的回到类别为 undefined。
// ✅ Works in Type 5.1!takesFunction( functionf( ) { // ^ return type is undefined// no returns});
// ✅ Works in Type 5.1!takesFunction( functionf( ) { // ^ return type is undefined
return; });
为介绍决另一个类似的痛点，在 Type 的 –noImplicitReturns 选项下，仅回到 undefined 的表达式现在具有与 void 类似的异常，即使并非每个标识符路径都必须以显式回到结束。
// ✅ Works in Type 5.1 under –noImplicitReturns!functionf( ): undefined{ if( Math.random) { // do some stuff…return; }}getter 和 setter 的不相关类别
Type 4.3 使得 get 和 set 访问器对能指定两种不同的类别成为可能将。最初他们要求 get 类别必须是 set 类别的子类型。这意味著写
box. value= box. value;永远有效。
但是，有许多现有的和提议的 API 在它们的 getter 和 setter 间具有完全不相关的类别。例如，考虑一个最常见的例子 DOM 和 CSSStyleRule API 中的样式特性。每个样式规则都有一个样式特性，即 CSSStyleDeclaration。但是，假如您尝试写入该特性，它只能采用字符串才能正常工作。
Type 5.1 现在允许完全不相关的类别用于 get 和 set 访问器特性，前提是它们具有显式类别注释。虽然此版的 Type 尚未更动那些内置接口的类别，但现在能透过以下方式定义 CSSStyleRule：
interfaceCSSStyleRule{ // …/** Always reads as a `CSSStyleDeclaration` */getstyle( ): CSSStyleDeclaration;
/** Can only write a `string` here. */setstyle( newValue: string) ;
// …}
这也允许其他模式，例如要求 set 访问器仅接受“有效”数据，但假如某些底层状态尚未初始化，则指定 get 访问器可能将会回到 undefined。
classSafeBox{ #value: string | undefined;// Only accepts strings!setvalue( newValue: string) {
}
// Must check for undefined!getvalue( ): string| undefined{ returnthis. #value;}}
实际上，这类似于在 –exactOptionalProperties 下检查和可选特性的方式。
JSX 原素和 JSX 条码类别间的解耦类别检查和
Type 对 JSX 的一个痛点是它对每个 JSX 原素条码类别的要求。此版的 Type 使 JSX 库能更准确地叙述 JSX 组件能回到的内容。对于许多人来说，这具体意味著能在 React 中采用异步服务器组件。
对于某些上下文和背景，JSX 原素是以下之一：
// A self-closing JSX tag<Foo />// A regular element with an opening/closing tag<Bar> </ Bar>
话说，它寻找 JSX.Element。
容性（或者假如类别是可构造的，则检查和另一类称作 JSX.ElementClass 的类别）。
这里的限制意味著假如组件回到或者假如它们“呈现”比 JSX.Element 更广泛的类别，则无法采用组件。例如，JSX 库可能将适合组件回到字符串或 Promises。
举一个更具体的例子，React 的未来版提议对回到 Promises 的组件提供更多有限全力支持，但现有版的 Type 无法表达这一点，除非有人彻底放宽 JSX.Element 的类别。
为了向库提供更多一类表达方式，Type 5.1 现在查找一类名为 JSX.ElementType 的类别。ElementType 精确指定甚么能有效用作 JSX 原素中的标记。所以那时可能将会输入类似：
namespaceJSX { exporttypeElementType = // All the valid lowercase tagskeyof IntrinsicAttributes// Function components(props: any) => Element // Class componentsnew(props: any) => ElementClass;exportinterfaceIntrinsictAttributes extends/*…*/ {} exporttypeElement = /*…*/; exporttypeClassElement =/*…*/; }
重新命名内部空间 JSX 特性
采用 JSX 时，Type 现在全力支持重新命名内部空间特性名称。
import * asReact from“react”;// Both of these are equivalent:constx = <Foo a:b= “hello”/>; consty = <Foo a : b= “hello”/>;
interfaceFooProps{ “a:b”: string; }
function Foo( props: FooProps) { return<div>{props[ “a:b”]}</div>; }
当名称的第一部分是小写名称时，在 JSX.IntrinsicAttributes 上以类似的方式查找重新命名内部空间条码名称。
// In some librarys code or in an augmentation of that library:namespaceJSX{ interfaceIntrinsicElements{ [ “a:b”]: { prop: string}; }}// In our code:letx = <a:b prop= “hello!”/>;
typeRoots 在组件导出中被查阅
当 Type 指定的组件查找策略无法导出路径时，它现在将导出相对于指定 typeRoots 的包。
相关详细重要信息，请参阅：https://github.com/microsoft/Type/pull/51715。
JSX 条码的镜像滑鼠
Type 现在全力支持 JSX 条码名称的镜像编辑。镜像编辑（有时称作“镜像滑鼠”）允许GUI自动同时编辑多个位置。
这项新功能应该适用于 Type 和 Java 文档，因此能在 Visual Studio Code Insiders 中启用。在 Visual Studio Code 中，您能编辑GUI——设置 UI 中的镜像编辑选项：
或在您的 JSON 设置文档中配置 editor.linkedEditing：
{// …“editor.linkedEditing”: true, }Visual Studio 17.7 Preview 1 也将全力支持此功能。
@param JSDoc 条码的短片顺利完成
在 Type 和 Java 文档中输入 @param 条码时，Type 现在提供更多短片补全。这有助于减少在撰写标识符文档或在 Java 中加进 JSDoc 类别时输入和跳转文本的次数。
优化
▍避免不必要的类别实例化
Type 5.1 现在避免在已知不包含对外部类别参数的引用的对象类别中执行类别实例化。这有可能将减少许多不必要的计算，并将 material-ui 的文档目录的类别检查和天数减少50%以上。
▍联合类别否定案例的检查和
在检查和源类别是否属于联合类别时，Type 首先采用该源的内部类别标识符进行快速查找。假如查找失败，则 Type 会检查每个联合中的类别兼容性。
当将字面量类别与纯字面量类别关联到一个联合中时，Type 现在能避免完全遍历所有其他类别。这个假定是安全的，即使 Type 总是实现/缓存文字类别——尽管有许多与“新”文字类别相关的边缘情况需要处理。
此优化能够将本期标识符的类别检查和天数从大约45秒减少到大约0.4秒。
▍减少对扫描器的调用以进行 JSDoc 导出
当旧版的 Type 导出出 JSDoc 注释时，它们会采用扫描器/分词器将注释分解为细粒度的标记并将内容拼凑在一起。这可能将有助于规范化评论文本，这样多个空格就会合并为一个；但它非常“喋喋不休”，意味著导出器和扫描器会经常来回跳转，从而增加 JSDoc 导出的开销。
Type 5.1 在将 JSDoc 注释分解为扫描器/分词器方面移动了更多方法论。扫描器现在将更大的内容块直接回到给导出器以根据需要进行处理。
那些更动已将几个 10Mb 的 Java 文档的导出天数缩短了大约一半。举一个更真实的例子，他们的性能套件的 xstate 快照减少了大约300毫秒的导出天数，使其加载和分析速度更快。
他们的团队早已在努力开发 Type 5.2，您能写作 Type 5.2 迭代计划中的详细重要信息。除了计划的工作项之外，此迭代计划还叙述了目标正式发布日期，您能将其用于自己的计划。他们希望您喜欢 Type 5.1，希望这个版能让您享受编码的乐趣。
Happy Hacking!
