在本文中，我们将讨论为什么启用严格的TypeScript编译器标记“艰难的方式”对于改进类型安全来说长期是值得的。
去年夏天，一组工程师将我们的前端代码从Closure-annotated JavaScript转换为TypeScript，您可以在这里阅读。将转换后的代码转换any为习惯用法和类型安全的TypeScript 是一段漫长的旅程。严格的编译器标志是进行这些改进的主要方法。仔细阅读以了解为什么启用严格的TypeScript编译器标记“艰难的方式”对于改进类型安全来说是值得的。
严格的标志
TypeScript编译器目前拥有8个严格的编译器标志，可用作工具来提高代码质量，并在不同程度上提高TypeScript类型系统的可靠性：
- noImplicitThis
- noImplicitReturns
- noUnusedLocals
- noUnusedParameters
- noImplicitAny
- strictNullChecks
- strictFunctionTypes
- strictPropertyInitialization
* alwaysStrict也包含在该strict标志中，但与其他标志不同，它显着地修改了发射。
我和任何在TypeScript代码库中工作过的人都可以证明严格标志的值，但是在现有代码库上启用标志的过程可以采用几种不同的方式。
简单的方法
TSLint和Tsetse都是为TypeScript创建的linters，包括针对某些规则的自动修复程序。例如，noImplicitAny用于
function example(val) {
编译器会输出一个错误
Error at srcfile.ts:11:18: Parameter 'val' implicitly has an 'any' type.
错误可以通过: any 在列18（从错误）+开始插入来解决 "val".length = 21。
function example(val: any) {
这对于程序自动执行而言非常简单 - 所有错误 noImplicitAny 都可以轻松解决，并且在一天结束时，您可以让您的百万行代码库完全符合严格的编译器标志。
艰难的路
另一种启用严格编译器标志的方法是逐个检查编译器中的每条错误消息，解决每个错误。
如果你和我一样，你可能只是笑了这个想法，但让我说服你，这种方法的好处是值得的。
问问自己，启用严格标志的原因是什么。答案很明显：你想创建一个健全的，类型安全的代码库。将明确的anys 添加到发现错误的每个位置对于提高现在的类型安全性并没有什么作用，并且强制未来的代码遵守将没有什么好处，而与无意中用有感染性的覆盖有效类型信息所造成的危害相比，这没有什么好处any。
考虑这个简单的代码示例。
declare function getInputs(): any;
getInputs().forEach((input) => console.log(input.property.value));
noImplicitAny会抛出一个input隐含的任何错误。如果我们是一个机器人，我们会天真地通过写作来消除这个错误，并(input: any) => ...愉快地启用noImplicitAny，并且庆幸我们的代码现在保持了更高的标准。但现在想象另一位工程师更新API getInputs，现在我们有：
declare function getInputs(): string[];
getInputs().forEach((input: any) => console.log(input.property.value));
这段代码 - 不幸 - 也编译，但会在运行时抛出一个错误。如果input没有用an注释 any，这段代码将无法编译，而改变API的工程师将能够解决问题。但是，通过明确注释类型，该机会就失去了。通过选择通向严格标志的简易路径，有可能失去您希望通过启用它们而获得的好处。
如果一个人看着这个相同的代码，他们可以假设getInputs返回一个数组并且至少改变类型any[]，如果不是更具体的类型的话。
两全其美
花了大约400个工程师小时才能noImplicitAny为我们的代码库手动启用标志。这个过程从开始到结束分散了150天。就代码而言，这是一段很长的时间。我是否建议你应该不带标志的好处，直到有人有足够的带宽来解决大型遗留代码库的数万错误？不，有办法获得增量收益。
通过将你的代码分割成独立的TypeScript项目（包括个人tsconfig.json的项目），你可以一次为一个项目启用严格标志，在其他项目正在进行时锁定增量类型安全。
尽管通过编程使符合严格的TypeScript编译器标志的代码能够锁定类型安全，但这样做的成本不应该被忽略。使用编译器错误作为资源将注意力引向改进类型而不是忽略它们不仅会阻止将来的类型被某个类型吸收，any而且还会提高代码的类型安全性，这可能是您希望通过使用TypeScript获得的值首先。
閱讀更多 愛碼農 的文章
關鍵字: 机器人 技术 JavaScript
