TypeScript4。9正式发布2022。11。15官文全

　　作者：DanielRosenwasser
　　原文日期：2022。11。15
　　原文链接：https：devblogs。microsoft。comtypescriptannouncingtypescript49
　　今天我们很高兴地发布TypeScript4。9。
　　如果你还不熟悉TypeScript，TypeScript是在JavaScript之上添加了类型的一个编程语言。类型帮助你标记代码的变量和函数的种类。TypeScript可以利用这些信息，帮助你消除拼写错误，或者是不小心忘记的null和undefined的检查。但是TypeScript提供的远比这些多，TypeScript可以用这些信息极大地提升你的开发体验，提供例如代码补全，跳转定义，重命名等功能。如果你已经用VisualStudio或者VisualStudioCode进行编写JavaScript的项目，你其实已经间接使用了TypeScript！
　　开始使用TypeScript，你可以通过NuGet，或者npm通过下面这个命令：npminstallDtypescript
　　你通过以下方式获取编辑器：下载VisualStudio20222019安装VisualStudioCode或者根据文档去使用更新版本的TypeScript
　　这里是TypeScript4。9更新的内容satifies操作符in操作符中未列举的属性收束Class的AutoAccessor对于NaN进行检查通过文件系统事件检测文件编辑器增强：RemoveUnusedImports和SortImports编辑器增强：对于return关键字的GotoDefinition性能增强正确性修复和破坏性改变从Beta和RC版本依赖的更新
　　相比RC版本，没有更多的变化加入到TypeScript4。9。Beta版本本来包括Class的AutoAccessor性能改进的部分，但是没有列出在文档上。satisfies操作符
　　TypeScript开发者经常面对这样一个难题：我们需要保证一些表达式匹配一些类型，但是又希望保留这个类型更具体的形状。
　　例如：每一个属性，既可以是RGB元组，也可以是一个字符串。constpalette｛red：〔255，0，0〕，green：00ff00，bleu：〔0，0，255〕sacrebleu这里故意写错了！｝；我们对于red使用数组的方法。。。constredComponentpalette。red。at（0）；或者对于green使用string的方法。。。constgreenNormalizedpalette。green。toUpperCase（）；
　　注意这里故意写成了bleu，而实际上应该写成blue。我们可以通过给palette加一个类型标准来避免这种问题，但是这样我们又失去具体一个属性的具体类型了。typeColorsredgreenblue；typeRGB〔red：number，green：number，blue：number〕；constpalette：RecordColors，stringRGB｛red：〔255，0，0〕，green：00ff00，bleu：〔0，0，255〕写错就会报错｝；但是red可能是一个string，而在上面的表达式中，实际是一个数组。constredComponentpalette。red。at（0）；
　　新的satisfies关键字就是用来解决这个问题的。satisfies可以用来校验一个更具体的形状是否符合预设的形状。我们用satisfies来解决上面的问题。typeColorsredgreenblue；typeRGB〔red：number，green：number，blue：number〕；constpalette｛red：〔255，0，0〕，green：00ff00，bleu：〔0，0，255〕写错就会报错，satisfies会去校验！｝satisfiesRecordColors，stringRGB；但是！constredComponentpalette。red。at（0）；constgreenNormalizedpalette。green。toUpperCase（）；
　　（Hugo注：satisfies能实现编译态和运行态更一致的类型关系，satisfies有点像ts的ts）
　　satisfies可以用来捕获很多可能的错误。例如，我们可以保证一个object的key只能是有限的集合中的结果。typeColorsredgreenblue；保证所有的key都来自Colors。constfavoriteColors｛red：yes，green：false，blue：kinda，platypus：falseerrorplatypus并不在Colors中。｝satisfiesRecordColors，unknown；所有关于red，green，和blue的属性信息都是和值声明一致的。constg：booleanfavoriteColors。green；
　　也许我们不关心object的key因为名称，而更关心value的类型。在下面的例子中，也可以解决这样的问题：typeRGB〔red：number，green：number，blue：number〕；constpalette｛red：〔255，0，0〕，green：00ff00，blue：〔0，0〕error！｝satisfiesRecordstring，stringRGB；所有值的类型和上面的值声明是一致的。constredComponentpalette。red。at（0）；constgreenNormalizedpalette。green。toUpperCase（）；
　　如果你想看更多的例子，可以查看issue和pr。我们感谢OleksandrTarasiuk实现了这个功能。in操作符中未列举的属性收束
　　作为开发者，我们经常需要处理程序运行时不完全知道的类型。事实上，我们从服务器或者配置文件读一个数据，并不能完全确定这个属性是否存在，JavaScript的in操作符提供了检查一个字段是否存在的手段。
　　在之前，TypeScript也提供了一定的对使用in操作符进行类型收束。interfaceRGB｛red：number；green：number；blue：number；｝interfaceHSV｛hue：number；saturation：number；value：number；｝functionsetColor（color：RGBHSV）｛if（hueincolor）｛colordHSV｝。。。｝
　　类型RGB并没有hue字段，所以可以进行类型收束，在in的block中，类型被收束为HSV。
　　但是，如果没有进行类型标准，会变成什么样子呢？functiontryGetPackageName（context）｛constpackageJSONcontext。packageJSON；检查我们收到的类型是一个object。if（packageJSONtypeofpackageJSONobject）｛检查存在name字段。if（nameinpackageJSONtypeofpackageJSON。namestring）｛returnpackageJSON。name；｝｝returnundefined；｝
　　把上面的例子改写为TypeScript，并使用unknown类型。interfaceContext｛packageJSON：unknown；｝functiontryGetPackageName（context：Context）｛constpackageJSONcontext。packageJSON；检查我们收到的类型是一个object。if（packageJSONtypeofpackageJSONobject）｛检查存在name字段。if（nameinpackageJSONtypeofpackageJSON。namestring）｛error！Propertynamedoesnotexistontypeobject。returnpackageJSON。name；error！Propertynamedoesnotexistontypeobject。｝｝returnundefined；｝
　　这里会报错是因为，在之前的版本，虽然unkown被收束为object，但是之后的收束并没有生效，TypeScript依然认为packageJSON只是一个object，而不知道有name这个字段。
　　TypeScript4。9会更智能，在通过in操作符以后，会给类型添加上断言添加的类型Recordpropertykeybeingchecked，unknown。
　　所以，在TypeScript4。9中，packageJSON的类型会先从unknown收束为object，然后继续收束为objectRecordname，unknown。这样后续的操作就知道packageJSON有name这个字段。interfaceContext｛packageJSON：unknown；｝functiontryGetPackageName（context：Context）：stringundefined｛constpackageJSONcontext。packageJSON；检查我们收到的类型是一个object。if（packageJSONtypeofpackageJSONobject）｛检查存在name字段。if（nameinpackageJSONtypeofpackageJSON。namestring）｛不会报错了！returnpackageJSON。name；｝｝returnundefined；｝
　　TypeScript也会对in操作符两端做检查，确保左边是stringnumbersymbol，右边是object。这会保证我们检查的左边是合法的key，而右边不是在检查一个基础类型。
　　更多的信息请查看pr。
　　（Hugo注，这个功能虽然简单，但是让TypeScript的断言能力进一步提升，在核心关键点写出更安全的代码提供了方便。）AutoAccessorsinClasses
　　TypeScript只吃了ECMAScript的新功能autoaccessors。autoaccessors就和class的属性一样，chclassPerson｛accessorname：string；constructor（name：string）｛this。namename；｝｝
　　上面这个写法，在最后会被去糖味get和set以及不可访问的原生私有属性。classPerson｛name：string；getname（）｛returnthis。name；｝setname（value：string）｛this。namename；｝constructor（name：string）｛this。namename；｝｝
　　对这个功能关心的话，请查看pr。对于NaN进行检查
　　对于JavaScript开发者来说，检查一个值和NaN的关系是一件不容易的事。
　　NaN是一个特殊的数字型值，表示不是一个数字。什么值和NaN都不相等，包括NaN自己。console。log（NaN0）falseconsole。log（NaN0）falseconsole。log（NaNNaN）falseconsole。log（NaNNaN）false
　　和这个等价的另一个规则是，任何东西都和NaN不相等。console。log（NaN！0）trueconsole。log（NaN！0）trueconsole。log（NaN！NaN）trueconsole。log（NaN！NaN）true
　　这个奇怪的行为并不是JavaScript独有的，任何语言只要实现了IEEE754floats标准，就会有这个行为。但是JavaScript的原生数字类型是一个浮点数型数字值，并且JavaScript的数字解析经常会出现NaN。检查和NaN在处理数字相关的代码时，是非常常见的。通常使用Number。isNaN，但是就像上面提到的，很多开发者实际使用someValueNaN来实现这个功能。
　　TypeScript会对NaN的直接比较进行报错，提示开发者使用Number。isNaN（Hugo注：多么贴心的功能。）。functionvalidate（someValue：number）｛returnsomeValue！NaN；error：Thisconditionwillalwaysreturntrue。Didyoumean！Number。isNaN（someValue）？｝
　　我们认为这个改变能帮助新手开发者防止错误，就像TypeScript目前不可以比较object和array一样。
　　感谢OleksandrTarasiuk贡献了这个PR。通过文件系统事件检测文件
　　在早期的版本里，TypeScript非常依赖轮训来检测单个文件。使用轮训的机制表示，TypeScript需要周期的检查一个文件。在Node。js里，fs。watchFIle时内置的获取轮训文件检测器的内置方法。因为轮训的机制在不同的平台和文件系统中是比较确定的，它会时不时终端CPU来看这个文件的状态，即便这个文件啥也没做，也要发生中断。如果文件不多，这个机制是合适的。但是如果文件特别多，比如nodemodules里的那么多文件，这种机制会造成一些资源占用浪费。
　　通常来说，比较好的方法是通过文件系统事件来实现上面的机制。不再使用轮训的机制，我们可以关注关心的文件，然后通过事件触发的回调来实现。绝大部分现代平台提供了CreateIoCompletionPort，kqueue，epoll，和inotify。Node。js提供了〔fs。watch〕（），这个接口抽象了这些实现方式。使用fs。watch接口来使用文件系统事件通常工作很好，但是也有一些缺陷。一个检测者要小心考虑inodewatching，在一些文件系统不可用（比如网络文件系统）。是否有递归文件检测是可用的，文件夹改名是否触发事件，还有文件检测者耗尽的问题。换句话说，使用这个机制，需要考虑非常多的问题，尤其是在跨平台使用时。
　　所以目前的解决方案时，我们默认的方法是在绝大部分时间使用轮训。
　　随着时间发展，我们会提供其他的文件检测机制。这让我们可以更多地获得关于跨平台碰到相关问题的反馈。因为TypeScript的项目会扩展为非常大的代码库，我们认为切换到基于文件事件的机制是值得投资的事情。
　　在TypeScript4。9，文件检测默认使用文件系统事件，只有在设置事件检测者失败时回退成轮训的机制。对于绝大部份开发者，使用watch模式可以消耗更少的资源，在使用TypeScript强化的编辑器例如VisualStudio或者VSCode时也会使用更少的资源。
　　使用watchOptions可以改变这个机制。VSCode也提供了改变这个参数的方法。如果开发者使用网络文件系统（例如NFS和SMB），需要把这个参数回退成轮训的机制，当然直接在服务器端使用TypeScript也是一个不错的选择，这样就是使用本地文件系统了。VSCode有很多关于远程开发的插件来帮助这个过程。
　　你可以在这篇文章看到关于这个问题更多的信息。编辑器增强：RemoveUnusedImports和SortImports
　　在之前的版本，TypeScript只支持两个编辑器命令来管理import。例如import｛Zebra，Moose，HoneyBadger｝from。zoo；import｛foo，bar｝from。helper；letx：MooseHoneyBadgerfoo（）；
　　第一个时OrganizeImports，会把不使用的imports移除，然后对剩下的import进行排序。上面的文件会被重写为：import｛foo｝from。helper；import｛HoneyBadger，Moose｝from。zoo；letx：MooseHoneyBadgerfoo（）；
　　在TypeScript4。3，我们引入了SortImport命令，可以只对文件进行排序，而不移除它们，使用这个功能会让一开始的代码变为import｛bar，foo｝from。helper；import｛HoneyBadger，Moose，Zebra｝from。zoo；letx：MooseHoneyBadgerfoo（）；
　　使用SortImports的缺陷是，在VisualStudioCode中，这个功能只能是保存时调用的功能，而不是手动触发的功能。
　　TypeScript4。9增加了另一半功能，即RemoveUnusedImports，TypeScript可以移除不使用的import和语句，把剩下的代码留下。import｛Moose，HoneyBadger｝from。zoo；import｛foo｝from。helper；letx：MooseHoneyBadgerfoo（）；
　　这个功能对于全部编辑器可用，但是注意VisualStudioCode（1。73和之后）会支持内置的可以在命令面板调用的这些功能。用户如果想更细粒度地控制这个行为，可以混合调用RemoveUnusedImports、SortImports和OrganizeImports。
　　更详细的文档请参考。编辑器增强：对于return关键字的GotoDefinition
　　在编辑器中，当对return关键字执行gotodefinition，TypeScript会跳到相关函数的顶部。这对于知道这个return属于哪个函数是有帮助的。
　　我们期望TypeScript可以扩展这个行为到更多的关键字，比如await和yield，switch、case和default。
　　感谢OleksandrTarasiuk提供了这个实现。性能增强
　　TypeScript有了一些小但是值得注意的性能增强。
　　首先，TypeScript的forEachChild函数使用函数表查找重写了switch语句的实现。编译器在进行语法节点遍历时非常依赖forEachChild，并且在语言服务器的编译器链接阶段也用的很重。重构forEachChild带来了绑定阶段大约20的性能提升。
　　当我们最终发现这个优化对于forEachChild的实现很有效果，我们在visitEachChild（这个函数在编译器和语言服务器中进行转换节点的工作）也做一样的优化。这样大概提升了visitEachChild3的性能。
　　最开始对于forEachChild优化的启发是来自ArtemisEverfree的博客。虽然我们认为目前速度的问题更多是函数的大小和复杂性有关，并不是博文中指出的问题，但是我们对于从这个经验中找到这个优化方法是非常感激的。
　　最后，对于TypeScript在条件分支中保留类型信息做了一些优化，对于类型interfaceZooTextendsAnimal｛。。。｝typeMakeZooAextendsAnimal？Zoo：never；
　　TypeScript在检查Zoo是合法时需要知道A是一个Animal。在之前的版本，TypeScript总是立即做了这件事，目前看是不必要的。并且，一些我们的类型检查器中的错误代码让我们无法简化这个过程。TypeScript现在推迟到必须知道这个类型时再去检查类型。对于使用条件类型非常多的代码库，能看到非常大的性能提升，对于常规情况，我们看到3的类型检查时间提升。
　　你可以阅读下面的PR来了解更详细的信息〔forEachChildasajumptable〕（https：github。commicrosoftTypeScriptpull50225）〔visitEachChildasajumptable〕（https：github。commicrosoftTypeScriptpull50266）Optimizesubstititiontypes正确性修复和破坏性改变更新lib。d。ts
　　虽然TypeScript尽量避免大的破坏式更新，因为内置库的一点小变化也会导致一些问题，但是关于DOM和lib。d。ts仍然会有一些小的破坏式更新。对于Promise。resolve的类型增强
　　Promise。resolve现在使用Awaited类型来对Proimselike的类型进行解包。这意味着现在更多返回正确的Promise的类型，而不是any或者unknown。更与这个变更更多请参考。JavaScript不再触发省略import
　　当TypeScript编译器开始支持JavaScript的类型检查和编译时，TypeScript引入了一些机制，例如省略import。这个功能的意思是，如果编译器发现一个引入的东西不作为值，则会在最终生成的文件省略这个import。
　　现在，TypeScript会保留这些import。输入：import｛someValue，SomeClass｝fromsomemodule；type｛SomeClass｝letvalsomeValue；之前版本的输出：import｛someValue｝fromsomemodule；type｛SomeClass｝letvalsomeValue；现在的输出：import｛someValue，SomeClass｝fromsomemodule；type｛SomeClass｝letvalsomeValue；
　　更多关于这个内容的信息参考。exports优先级高于typesVersions
　　在之前的版本中，当TypeScript解析package。json通过moduleResolutionnode16时，TypeScript会错误提升typesVersions的优先级高于exports。如果这个改变影响你的库，你需要增加types字段。｛type：module，main：。distmain。jstypesVersions：｛4。8：｛。：〔4。8typesmain。d。ts〕｝，：｛。：〔moderntypesmain。d。ts〕｝｝，exports：｛。：｛types4。8：4。8typesmain。d。ts，types：moderntypesmain。d。ts，import：。distmain。js｝｝｝
　　更多信息参考。（Hugo注：这种类型的功能，建议等三个版本再上生产。）对于SubstitutionType的substitute替换为constraint
　　对于替换类型的优化，SubstitutionType对象不在包含substitute属性，substitute属性代表高效替换，通常是基础类型和隐式限制的交集。现在SubstitutionType值包含constraint属性。
　　更多信息，参考。下一步
　　我们目前发布了了5。0版本的迭代计划，里面有很多有趣的功能！如果你感兴趣，我们期望你们能来看看。
　　期望4。9让你的代码旅途更快乐。
　　HappyHacking！
　　DanielRosenwasserandtheTypeScriptTeam