SitePen是TypeScript的巨大倡导者，也是拥有良好类型代码的好处。当中型和大型团队使用TypeScript时，尤其强大，他们希望找到方法来增加他们对代码的整体信心。我们经常被问到的一个问题是，我们如何将目前用JavaScript编写的代码库迁移到TypeScript。我们的许多客户很高兴地发现，类型检查可以逐步添加，而不需要进行重大的重写或大量的前期成本。
这篇文章将帮助指导你逐步将TypeScript添加到一个JavaScript应用程序。像所有的项目一样，我们强烈建议从你的团队中了解他们的期望，并了解你的项目在哪些方面可以从类型系统中获得最大的利益，并付出最少的努力。初次接触TypeScript编码？请先阅读我们的TypeScript 指南。
将 TypeScript 添加到 JavaScript 应用程序的第一步
将 TypeScript 添加到项目的第一步是添加 tsconfig 文件，该文件配置 TypeScript 编译器和项目或应用程序中的相关资源。TypeScript可以通过使用npm install typescript ，在你的项目中安装TypeScript并运行tsc --init ，自动为你创建这个文件。
现在我们有一个tsconfig，我们需要指示TypeScript编译器对JavaScript文件进行类型检查。我们可以通过添加 allowJS, checkJS, 和 noEmit 配置标志来实现这一点：
{
"compilerOptions": {
"target": "es5",
"module": "commonjs",
"jsx": "react",
"noEmit": true,
"allowJs": true,
"checkJs": true,
"strict": true
}
}
tsconfig文件样本
allowJS 和checkJS 标志指示TypeScript编译器编译和检查JavaScript文件的类型错误。TypeScript通过基于赋值和JSDoc注释（如果有的话）对代码进行一些假设来完成这个任务。noEmit选项告诉TypeScript，我们只想运行类型检查，而不希望编译器输出任何转义的代码。
一旦有了tsconfig文件，VSCode（或你最喜欢的IDE）应该检测到TypeScript的使用，并自动对你的代码进行类型检查。你也可以从命令行中运行tsc ，如果存在任何问题，它将返回一个类型警告的列表和一个非零的退出代码。
解决JavaScript中的类型警告
TypeScript在首次运行时报告数以百计的类型警告是很正常的。不要担心，这些警告中的大多数都很容易解决。在我们更新你的tsconfig并向编译器提供任何缺失的类型信息后，这些警告大多会消失。在接下来的章节中，我们将使用编译器选项。TypeScript手册中有一个所有TypeScript编译器选项的列表。
首先，确保tsconfig的目标属性与你的项目所使用的ECMAScript的版本相匹配。大多数Node.js项目、Babel项目或者只针对现代浏览器的项目都需要改变这个值。你也可以使用lib选项明确地提供一个要包含的库的列表。当TypeScript发现任何代码与你所添加的ECMAScript和库的版本不匹配时，它会告诉你。
TypeScript警告说，Set是在ES2015中添加的，这可能是一个潜在的错误。
接下来，你的应用程序的外部依赖的类型需要被添加到你的项目中。.一些项目将包括他们自己的类型定义集，将自动被TypeScript使用。大多数其他项目将在Definitely Typed上提供环境类型。环境类型只包括一个项目的类型定义（即只有类型，没有代码），它们被TypeScript用来理解外部库。类型定义可以通过npm的@types组来安装。例如，要安装React类型，运行npm install @types/react 。
这个错误是由于缺少React类型。安装@types/react将解决这个问题。
React，或者其他使用JSX的项目，需要在他们的tsconfig文件中加入jsx选项（通常是tsx："react"）。这将告诉 TypeScript 使用其 JSX 解析器来识别 JSX 语法和使用的问题。
这个错误表明缺少jsx标志。
到此为止，任何剩余的类型警告都应该与你项目的源代码直接相关。你将需要浏览剩余的错误，并确定警告是否代表需要解决的实际问题，或者警告是由于TypeScript不正确地从代码中推断出类型。有很多方法可以解决后者，要么提供更准确的类型信息，要么完全忽略有问题的类型、行或文件。
解决类型警告的最好方法之一是向TypeScript提供正确的类型信息。在JavaScript代码库中做到这一点的最好方法是使用JSDoc。TypeScript使用JSDoc注释来解决类型问题，注释有助于识别和执行类型化的值。更复杂的类型可以在一个.d.ts文件中定义。这个文件应该和它所提供的类型的文件名称相同，TypeScript将以使用Definitely Typed的类型的相同方式使用这个文件。虽然这对使用TypeScript的类型系统表达更复杂的类型很有好处，但它确实有一个缺点，即存在于一个单独的文件中，这可能导致对代码库进行更新时忘记更新相应的类型定义。
解决类型警告的另一种方法是忽略它们。TypeScript有几个注释可以提供，以表明文件应该如何被检查：
@ts-nocheck将告诉编译器跳过对整个文件的检查@ts-ignore将跳过检查下一行@ts-expect-error(TS 3.9+)与 ，但如果没有发现类型错误，将产生一个错误。@ts-ignore
另一个选择是在.d.ts文件中把模块的导入和导出作为任意输入。TypeScript编译器将看到这一点，并允许该值以任何方式使用。最后，如果你的tsconfig文件设置了strict选项，这将为编译器开启一些严格的检查选项。将strict设置为false或禁用一些严格检查选项，如noImplicitAny，可以消除一整类错误。
值得注意的是，通过块排除、任何类型或将严格设置为false来忽略类型警告会使你的代码库的类型安全性降低。从长远来看，值得确保类型是正确的，并尽可能地与你的代码库中最常用的部分相关。
TypeScript和webpack
一旦你解决了由TypeScript编译器引起的大部分类型警告，你就可以考虑将TypeScript集成到你的构建过程中。对于webpack来说，这就像添加ts-loader模块并将其作为webpack配置的一部分那么简单。如果你的tsconfig文件将noEmit设置为false，那么它也应该被删除，这样webpack就会收到TypeScript的输出。Webpack有一个关于将TypeScript添加到Webpack构建中的优秀指南。
TypeScript和Babel
Babel对使用TypeScript作为类型检查器有很好的支持。这对于那些想增加类型安全而又不想把转译器改为TypeScript的团队来说是非常好的。只需在项目的babel配置中添加@babel/preset-typescript ，并确保tsconfig文件中的noEmit为true。
总结
TypeScript团队花了很大的力气，使逐步添加类型检查到现有的项目中成为一种快速和无痛的体验。编译器在通过使用自动推断类型和捕捉常见错误方面比以往更加智能。
我们强烈建议任何团队考虑将TypeScript添加到他们现有的项目中。类型安全的代码使团队能够在更短的时间内写出更好的代码，并且更加自信。当添加到持续集成中时，TypeScript 将消除一大类常见的错误和假设，这些错误和假设往往会溜到生产中并毁掉你的一天。
