為什么說用 Babel 編譯 Typescript 是更好的選擇
本文轉(zhuǎn)載自微信公眾號(hào)「神光的編程秘籍」，作者神說要有光。轉(zhuǎn)載本文請(qǐng)聯(lián)系神光的編程秘籍公眾號(hào)。
typescript 給 javascript 擴(kuò)展了類型的語法和語義，讓 js 代碼達(dá)到了靜態(tài)類型語言級(jí)別的類型安全，之前只能在運(yùn)行時(shí)發(fā)現(xiàn)的類型不安全的問題，現(xiàn)在能在編譯期間發(fā)現(xiàn)了，所以大項(xiàng)目越來越多的選擇用 typescript 來寫。除此之外，typescript 還能夠配合 ide 做更好的智能提示，這也是用 typescript 的一個(gè)理由。
類型安全：如果一個(gè)類型的變量賦值給它不兼容類型的值，這就是類型不安全，如果一個(gè)類型的對(duì)象，調(diào)用了它沒有的方法，這也是類型不安全。反之，就是類型安全。類型安全就是變量的賦值、對(duì)象的函數(shù)調(diào)用都是在類型支持的范圍內(nèi)。
最開始 typescript 代碼只有自帶的 tyepscript compiler(tsc)能編譯，編譯不同版本的 typescript 代碼需要用不同版本的 tsc，通過配置 tsconfig.json 來指定如何編譯。
但是 tsc 編譯 ts 代碼為 js 是有問題的：
tsc 不支持很多還在草案階段的語法，這些語法都是通過 babel 插件來支持的，所以很多項(xiàng)目的工具鏈?zhǔn)怯?tsc 編譯一遍 ts 代碼，之后再由 babel 編譯一遍。這樣編譯鏈路長(zhǎng)，而且生成的代碼也不夠精簡(jiǎn)。
所以，typescript 找 babel 團(tuán)隊(duì)合作，在 babel7 中支持了 typescript 的編譯，可以通過插件來指定 ts 語法的編譯。比如 api 中是這樣用：
- const parser = require('@babel/parser');
- parser.parse(sourceCode, {
- plugins: ['typescript']
- });
這個(gè)插件是 typescript 團(tuán)隊(duì)與 babel 團(tuán)隊(duì)合作了一年的成果。
但是，這個(gè)插件真的能支持所有 typescript 代碼么?答案是否定的。
我們來看一下 babel 不支持哪些 ts 語法，為什么不支持。
babel 能編譯所有 typescript 代碼么?
babel 的編譯流程是這樣的：
- parser: 把源碼 parse 成 ast
- traverse：遍歷 ast，生成作用域信息和 path，調(diào)用各種插件來對(duì) ast 進(jìn)行轉(zhuǎn)換
- generator：把轉(zhuǎn)換以后的 ast 打印成目標(biāo)代碼，并生成 sourcemap
而 typescript compiler 的編譯流程是這樣的：
- scanner + parser：分詞和組裝 ast，從源碼到 ast 的過程
- binder + checker：生成作用域信息，進(jìn)行類型推導(dǎo)和檢查
- transform：對(duì)經(jīng)過類型檢查之后的 ast 進(jìn)行轉(zhuǎn)換
emitter：打印 ast 成目標(biāo)代碼，生成 sourcemap 和類型聲明文件(根據(jù)配置)
其實(shí) babel 的編譯階段和 tsc 的編譯階段是類似的，只是 tsc 多了一個(gè) checker，其余的部分沒什么區(qū)別。
- babel 的 parser 對(duì)應(yīng) tsc 的 scanner + parser
- babel 的 traverse 階段 對(duì)應(yīng) tsc 的 binder + transform
- babel 的 generator 對(duì)應(yīng) tsc 的 emitter
那么能不能基于 babel 的插件在 traverse 的時(shí)候?qū)崿F(xiàn) checker 呢?
答案是不可以。
因?yàn)?tsc 的類型檢查是需要拿到整個(gè)工程的類型信息，需要做類型的引入、多個(gè)文件的 namespace、enum、interface 等的合并，而 babel 是單個(gè)文件編譯的，不會(huì)解析其他文件的信息。所以做不到和 tsc 一樣的類型檢查。
一個(gè)是在編譯過程中解析多個(gè)文件，一個(gè)是編譯過程只針對(duì)單個(gè)文件，流程上的不同，導(dǎo)致 babel 無法做 tsc 的類型檢查。
那么 babel 是怎么編譯 typescript 的呢?
其實(shí) babel 只是能夠 parse ts 代碼成 ast，不會(huì)做類型檢查，會(huì)直接把類型信息去掉，然后打印成目標(biāo)代碼。
這導(dǎo)致了有一些 ts 語法是 babel 所不支持的：
- const enum 不支持。const enum 是在編譯期間把 enum 的引用替換成具體的值，需要解析類型信息，而 babel 并不會(huì)解析，所以不支持?？梢杂孟鄳?yīng)的插件把 const enum 轉(zhuǎn)成 enum。
- namespace 部分支持。不支持 namespace 的跨文件合并，不支持導(dǎo)出非 const 的值。這也是因?yàn)?babel 不會(huì)解析類型信息且是單文件編譯。
上面兩種兩個(gè)是因?yàn)榫幾g方式的不同導(dǎo)致的不支持。
- export = import = 這種 ts 特有語法不支持，可以通過插件轉(zhuǎn)為 esm
- 如果開啟了 jsx 編譯，那么
aa 這種類型斷言不支持，通過 aa as string 來替代。這是因?yàn)檫@兩種語法有沖突，在兩個(gè)語法插件(jsx、typescript)里，解決沖突的方式就是用 as 代替。
這四種就是 babel 不支持的 ts 語法，其實(shí)影響并不大，這幾個(gè)特性不用就好了。
結(jié)論：babel 不能編譯所有 typescript 代碼，但是除了 namespace 的兩個(gè)特性外，其余的都可以做編譯。
babel 是可以編譯 typescript 代碼，那么為什么要用 babel 編譯呢?
為什么要用 babel 編譯 typescript 代碼?
babel 編譯 typescript 代碼有 3 個(gè)主要的優(yōu)點(diǎn)：
產(chǎn)物體積更小
tsc
tsc 如何配置編譯目標(biāo)呢?
在 compilerOptions 里面配置 target，target 設(shè)置目標(biāo)語言版本
- {
- compilerOptions: {
- target: "es5" // es3、es2015
- }
- }
typescript 如何引入 polyfill 呢?
在入口文件里面引入 core-js.
- import 'core-js';
babel7
babel7 是如何配置編譯目標(biāo)呢?
在 preset-env 里面指定 targets，直接指定目標(biāo)運(yùn)行環(huán)境(瀏覽器、node)版本，或者指定 query 字符串，由 browserslist 查出具體的版本。
- {
- presets: [
- [
- "@babel/preset-env",
- {
- targets: {
- chrome: 45
- }
- }
- ]
- ]
- }
- {
- presets: [
- [
- "@babel/preset-env",
- {
- targets: "last 1 version,> 1%,not dead"
- }
- ]
- ]
- }
babel7 如何引入 polyfill 呢?
也是在 @babel/preset-env 里面配置，除了指定 targets 之外，還要指定 polyfill 用哪個(gè)(corejs2 還是 corejs3)，如何引入(entry 在入口引入 ，usage 每個(gè)模塊單獨(dú)引入用到的)。
- {
- presets: [
- [
- "@babel/preset-env",
- {
- targets: "last 1 version,> 1%,not dead",
- corejs: 3,
- useBuiltIns: 'usage'
- }
- ]
- ]
- }
這樣可以根據(jù) @babel/compat-data 的數(shù)據(jù)來針對(duì)的做語法轉(zhuǎn)換和 api 的 polyfill：
先根據(jù) targets 查出支持的目標(biāo)環(huán)境的版本，再根據(jù)目標(biāo)環(huán)境的版本來從所有特性中過濾支持的，剩下的就是不支持的特性。只對(duì)這些特性做轉(zhuǎn)換和 polyfill 即可。
而且 babel 還可以通過 @babel/plugin-transform-runtime 來把全局的 corejs 的 import 轉(zhuǎn)成模塊化引入的方式。
顯然，用 babel 編譯 typescript 從產(chǎn)物上看有兩個(gè)優(yōu)點(diǎn)：
- 能夠做更精準(zhǔn)的按需編譯和 polyfill，產(chǎn)物體積更小
- 能夠通過插件來把 polyfill 變成模塊化的引入，不污染全局環(huán)境
從產(chǎn)物來看，babel 勝。
支持的語言特性
typescript 默認(rèn)支持很多 es 的特性，但是不支持還在草案階段的特性，babel 的 preset-env 支持所有標(biāo)準(zhǔn)特性，還可以通過 proposal 來支持更多還未進(jìn)入標(biāo)準(zhǔn)的特性。
- {
- plugins: ['@babel/proposal-xxx'],
- presets: ['@babel/presets-env', {...}]
- }
從支持的語言特性來看，babel 勝。
編譯速度
tsc 會(huì)在編譯過程中進(jìn)行類型檢查，類型檢查需要綜合多個(gè)文件的類型信息，要對(duì) AST 做類型推導(dǎo)，比較耗時(shí)，而 babel 不做類型檢查，所以編譯速度會(huì)快很多。
從編譯速度來看， babel 勝。
總之，從編譯產(chǎn)物大小(主要)、支持的語言特性、編譯速度來看，babel 完勝。
但是，babel 不做類型檢查，那怎么類型檢查呢?
babel 和 tsc 的結(jié)合
babel 可以編譯生成更小的產(chǎn)物，有更快的編譯速度和更多的特性支持，所以我們選擇用 babel 編譯 typescript 代碼。但是類型檢查也是需要的，可以在 npm scripts 中配一個(gè)命令：
- {
- "scripts": {
- "typeCheck": "tsc --noEmit"
- }
- }
這樣在需要進(jìn)行類型檢查的時(shí)候單獨(dú)執(zhí)行一下 npm run typeCheck 就行了，但最好在 git commit 的 hook 里(通過 husky 配置)再執(zhí)行一次強(qiáng)制的類型檢查。
總結(jié)
typescript 給 js 擴(kuò)展了靜態(tài)類型的支持，使得代碼能夠在編譯期間檢查出賦值類型不匹配、調(diào)用了沒有的方法等錯(cuò)誤，保證類型安全。
除了 tsc 之外，babel7 也能編譯 typescript 代碼了，這是兩個(gè)團(tuán)隊(duì)合作一年的結(jié)果。
但是 babel 因?yàn)閱挝募幾g的特點(diǎn)，做不了和 tsc 的多文件類型編譯一樣的效果，有幾個(gè)特性不支持(主要是 namespace 的跨文件合并、導(dǎo)出非 const 的值)，不過影響不大，整體是可用的。
babel 做代碼編譯，還是需要用 tsc 來進(jìn)行類型檢查，單獨(dú)執(zhí)行 tsc --noEmit 即可。
babel 編譯 ts 代碼，相比 tsc 有很多優(yōu)點(diǎn)：產(chǎn)物體積更小，支持更多特性，編譯速度更快。所以用 babel 編譯 typescript 是一個(gè)更好的選擇。
