为啥默认禁用 TypeScript 中的不安全/非严格编译器规则？

Posted 2023-03-24

【中文标题】为啥默认禁用 TypeScript 中的不安全/非严格编译器规则？

【英文标题】：Why unsecure/non-strict compilers rules in TypeScript are disabled by default?为什么默认禁用 TypeScript 中的不安全/非严格编译器规则？

【发布时间】：2019-09-01 17:36:33

【问题描述】：

最近在我的应用程序中，我不得不启用所有这些编译器选项：

"alwaysStrict": true,
"extendedDiagnostics": true,
"noFallthroughCasesInSwitch": true,
"noImplicitAny", true,
"noImplicitThis", true,
"noImplicitReturns": true,
"noUnusedLocals": true,
"noUnusedParameters": true,
"strict": true,
"strictBindCallApply": true,
"strictFunctionTypes": true,
"strictNullChecks": true,
"strictPropertyInitialization": true

它们用于更严格的编译，即更安全，我相信它们有助于实现更高质量的代码。我的问题是为什么默认情况下所有这些都被禁用。根据：https://www.typescriptlang.org/docs/handbook/compiler-options.html

【参考方案1】：

您已经可以通过简单地添加strict: true 来节省大量输入。它包括以下compiler settings：

--noImplicitAny
--noImplicitThis
--alwaysStrict
--strictBindCallApply
--strictNullChecks
--strictFunctionTypes
--strictPropertyInitialization

严格 默认情况下禁用。我想，这简化了从 JS 项目到 TypeScript 的增量迁移，并且在开始时不会造成太大的挫败感。

扩展诊断 由于它会出于调试目的输出详细的诊断信息，因此可能不适合作为默认设置。

noFallthroughCasesInSwitch 取决于您的编码风格。合并案例也有一些有效案例。

无隐式返回 已分类为stylistic matter。它不会影响类型安全，因为编译器可以推断返回类型，而无需显式声明它们。

noUnusedLocals/参数 TypeScript 有 functionality/IDE support 可以让 VS Code 之类的编辑器将未使用的局部变量和参数显示为未使用的建议，并具有单独的格式。所以你得到提示而不会受到太多编译错误的影响，例如当noEmitOnError: true.

【讨论】：

关于 strict: true 替换我知道的许多内容，只是想更明确地指出它。感谢您的详细解释:)