¿Qué compilador se usa para compilar el código TypeScript?
No hace falta decir que debe ser el compilador que viene con ts.
Pero, de hecho, babel también puede compilar código ts, entonces, ¿cuál es la diferencia entre usar babel y tsc para compilar código ts?
Veámoslos por separado:
Proceso de compilación de tsc
El proceso de compilación del compilador TypeScript es el siguiente:
El código fuente primero debe analizarse léxicamente con Scanner y dividirse en palabras que no se pueden subdividir, llamadas tokens.
Luego use Parser para analizar y ensamblarlo en un Abstract Syntax Tree AST.
Luego realice un análisis semántico, incluido el análisis de alcance con Binder, y verifique el tipo con Checker. Si hay un error de tipo, se informa en la etapa Checker.
Si hay un complemento de Transformer (tsc admite la transformación personalizada), se llamará después de Checker, y se pueden realizar varias adiciones, eliminaciones y cambios en el AST.
Después de pasar la verificación de tipo, Emiter usará Emiter para imprimir el AST en código objeto, generar el archivo de declaración de tipo d.ts y el mapa fuente.
La función del mapa fuente es asignar la ubicación del código del código fuente y el código de destino, de modo que el punto de interrupción se pueda ubicar en el código fuente correspondiente durante la depuración, y la ubicación del error del código fuente también se puede ubicar de acuerdo con el mapa fuente cuando un se informa un error en línea.
El AST generado por tsc se puede ver visualmente con astexplorer.net :
El código de objeto generado, los d.ts y los mensajes de error también se pueden ver directamente con ts playground :
Después de comprender aproximadamente el proceso de compilación de tsc, echemos un vistazo a babel:
Proceso de compilación de babel
El proceso de compilación de babel es el siguiente:
Parser analiza y analiza léxicamente el código fuente para generar token y AST.
AST realizará un análisis semántico para generar información de alcance y luego llamará a Transformer para convertir AST.
最后会用 Generator 把 AST 打印成目标代码并生成 sourcemap。
babel 的 AST 和 token 也可以用 astexplorer.net 可视化的查看：
如果想看到 tokens，需要点开设置，开启 tokens：
而且 babel 也有 playground（babel 的叫 repl） 可以直接看编译之后生成的代码：
其实对比下 tsc 的编译流程，区别并不大：
Parser 对应 tsc 的 Scanner 和 Parser，都是做词法分析和语法分析，只不过 babel 没有细分。
Transform 阶段做语义分析和代码转换，对应 tsc 的 Binder 和 Transformer。只不过 babel 不会做类型检查，没有 Checker。
Generator 做目标代码和 sourcemap 的生成，对应 tsc 的 Emitter。只不过因为没有类型信息，不会生成 d.ts。
对比两者的编译流程，会发现 babel 除了不会做类型检查和生成类型声明文件外，tsc 能做的事情，babel 都能做。
看起来好像是这样的，但是 babel 和 tsc 实现这些功能是有区别的：
babel 和 tsc 的区别
抛开类型检查和生成 d.ts 这俩 babel 不支持的功能不谈，我们看下其他功能的对比：
分别对比下语法支持和代码生成两方面：
语法支持
tsc 默认支持最新的 es 规范的语法和一些还在草案阶段的语法（比如 decorators），想支持新语法就要升级 tsc 的版本。
babel 是通过 @babel/preset-env 按照目标环境 targets 的配置自动引入需要用到的插件来支持标准语法，对于还在草案阶段的语法需要单独引入 @babel/proposal-xx 的插件来支持。
所以如果你只用标准语法，那用 tsc 或者 babel 都行，但是如果你想用一些草案阶段的语法，tsc 可能很多都不支持，而 babel 却可以引入 @babel/poposal-xx 的插件来支持。
从支持的语法特性上来说，babel 更多一些。
代码生成
tsc 生成的代码没有做 polyfill 的处理，想做兼容处理就需要在入口引入下 core-js（polyfill 的实现）。
import "core-js";
Promise.resolve;
复制代码babel 的 @babel/preset-env 可以根据 targets 的配置来自动引入需要的插件，引入需要用到的 core-js 模块，
引入方式可以通过 useBuiltIns 来配置：
entry 是在入口引入根据 targets 过滤出的所有需要用的 core-js。
usage 则是每个模块按照使用到了哪些来按需引入。
module.exports = {
presets: [
[
'@babel/preset-typescript',
'@babel/preset-env',
{
targets: '目标环境',
useBuiltIns: 'entry' // ‘usage’
}
]
]
}
复制代码此外，babel 会注入一些 helper 代码，可以通过 @babel/plugin-transform-runtime 插件抽离出来，从 @babel/runtime 包引入。
使用 transform-runtime 之前：
使用 transform-runtime 之后：
（transform runtime 顾名思义就是 transform to runtime，转换成从 runtime 包引入 helper 代码的方式）
所以一般babel 都会这么配：
module.exports = {
presets: [
[
'@babel/preset-typescript',
'@babel/preset-env',
{
targets: '目标环境',
useBuiltIns: 'usage' // ‘entry’
}
]
],
plugins: [ '@babel/plugin-transform-runtime']
}
复制代码当然，这里不是讲 babel 怎么配置，我们绕回主题，babel 和 tsc 生成代码的区别：
tsc 生成的代码没有做 polyfill 的处理，需要全量引入 core-js，而 babel 则可以用 @babel/preset-env 根据 targets 的配置来按需引入 core-js 的部分模块，所以生成的代码体积更小。
看起来用 babel 编译 ts 代码全是优点？
也不全是，babel 有一些 ts 语法并不支持：
babel 不支持的 ts 语法
babel 是每个文件单独编译的，而 tsc 不是，tsc 是整个项目一起编译，会处理类型声明文件，会做跨文件的类型声明合并，比如 namespace 和 interface 就可以跨文件合并。
所以 babel 编译 ts 代码有一些特性是没法支持的：
const enum 不支持
enum 编译之后是这样的：
而 const enum 编译之后是直接替换用到 enum 的地方为对应的值，是这样的：
const enum 是在编译期间把 enum 的引用替换成具体的值，需要解析类型信息，而 babel 并不会解析，所以它会把 const enum 转成 enum 来处理：
namespace 部分支持：不支持 namespace 的合并，不支持导出非 const 的值
比如这样一段 ts 代码：
namespace Guang {
export const name = 'guang';
}
namespace Guang {
export const name2 = name;
}
console.log(Guang.name2);
复制代码按理说 Guang.name2 是 'dong'，因为 ts 会自动合并同名 namespace。
ts 编译之后的代码是这样的：
都挂到了 Guang 这个对象上，所以 name2 就能取到 name 的值。
而 babel 对每个 namespace 都是单独处理，所以是这样的：
因为不会做 namespace 的合并，所以 name 为 undefined。
还有 namespace 不支持导出非 const 的值。
ts 的 namespace 是可以导出非 const 的值的，后面可以修改：
但是 babel 并不支持：
原因也是因为不会做 namespace 的解析，而 namespace 是全局的，如果在另一个文件改了 namespace 导出的值，babel 并不能处理。所以不支持对 namespace 导出的值做修改。
除此以外，还有一些语法也不支持：
部分语法不支持
像 export = import = 这种过时的模块语法并不支持：
开启了 jsx 编译之后，不能用 的方式做类型断言：
我们知道，ts 是可以做类型断言来修改某个类型到某个类型的，用 as xx 或者 的方式。
但是如果开启了 jsx 编译之后， 的形式会和 jsx 的语法冲突，所以就不支持 做类型断言了：
tsc 都不支持，babel 当然也是一样：
babel 不支持 ts 这些特性，那是否可以用 babel 编译 ts 呢？
babel 还是 tsc？
babel 不支持 const enum（会作为 enum 处理），不支持 namespace 的跨文件合并，导出非 const 的值，不支持过时的 export = import = 的模块语法。
这些其实影响并不大，只要代码里没用到这些语法，完全可以用 babel 来编译 ts。
babel 编译 ts 代码的优点是可以通过插件支持更多的语言特性，而且生成的代码是按照 targets 的配置按需引入 core-js 的，而 tsc 没做这方面的处理，只能全量引入。
而且 tsc 因为要做类型检查所以是比较慢的，而 babel 不做类型检查，编译会快很多。
那用 babel 编译，就不做类型检查了么？
可以用 tsc --noEmit 来做类型检查，加上 noEmit选项就不会生成代码了。
如果你要生成 d.ts，也要单独跑下 tsc 编译。
总结
babel 和 tsc 的编译流程大同小异，都有把源码转换成 AST 的 Parser，都会做语义分析（作用域分析）和 AST 的 transform，最后都会用 Generator（或者 Emitter）把 AST 打印成目标代码并生成 sourcemap。
但是 babel 不做类型检查，也不会生成 d.ts 文件。
tsc 支持最新的 es 标准特性和部分草案的特性（比如 decorator），而 babel 通过 @babel/preset-env 支持所有标准特性，也可以通过 @babel/proposal-xx 来支持各种非标准特性，支持的语言特性上 babel 更强一些。
tsc 没有做 polyfill 的处理，需要全量引入 core-js，而 babel 的 @babel/preset-env 会根据 targets 的配置按需引入 core-js，引入方式受 useBuiltIns 影响 (entry 是在入口引入 targets 需要的，usage 是每个模块引入用到的)。
但是 babel 因为是每个文件单独编译的（tsc 是整个项目一起编译），而且也不解析类型，所以 const enum，namespace 合并，namespace 导出非 const 值并不支持。而且过时的 export = 的模块语法也不支持。
但这些影响不大，完全可以用 babel 编译 ts 代码来生成体积更小的代码，不做类型检查编译速度也更快。
如果想做类型检查可以单独执行 tsc --noEmit。
当然，文中只是讨论了 tsc 和 babel 编译 ts 代码的区别，并没有说最好用什么，具体用什么编译 ts，大家可以根据场景自己选择。
（更多可以看我的 ts 小册《TypeScript 类型体操通关秘籍》，快更完了）