前端工具類項目規範化-使用TS

當咱們在開發維護一些工具類項目的時候，隨着功能的豐富以及維護人員的變動，會致使代碼的可持續維護性降低，所以須要一些其餘工具來幫咱們提升代碼質量，減小一些沒必要要的錯誤。本篇咱們來介紹使用TS來作一些事情。

什麼是TS

TypeScript 是微軟開發一款開源的編程語言，本質上是向 JavaScript 增長靜態類型系統。它是 JavaScript 的超集，全部現有的 JavaScript 均可以不加改變就在其中使用。它是爲大型軟件開發而設計的，它最終編譯產生 JavaScript，因此能夠運行在瀏覽器、Node.js 等等的運行時環境。

TS能作什麼

首先TS的定位是靜態類型語言，而不是類型檢查器（對比flow）。 從開發工具提供的能力看也不只僅是類型檢查，很直觀的就是Intellisense over Compilation Error，當一段代碼有問題（好比少寫了字母）時，寫完立刻就會有紅色波浪線提示，而不是等到編譯的時候才告訴你哪一行有問題。 所以使用TS提供的類型系統+靜態分析檢查+智能感知/提示，使大規模的應用代碼質量更高，運行時bug更少，更方便維護。

對比js有哪些優點

• 開發效率

雖然須要多寫一些類型定義代碼，但TS在WebStorm等IDE下能夠作到智能提示，智能感知bug，同時咱們項目經常使用的一些第三方類庫框架都有TS類型聲明（@types管理），咱們也能夠給那些沒有TS類型聲明的穩定模塊寫聲明文件，這在團隊協做項目中能夠提高總體的開發效率。

• 可維護性

長期迭代維護的項目開發和維護的成員會有不少，人員的不穩定性和團隊成員水平的差別的差別性，以及軟件自己具備熵的特質，致使長期迭代維護的項目總會遇到可維護性逐漸下降的問題。而有了強類型約束和靜態檢查，以及智能IDE的幫助下，能夠下降軟件腐化的速度，提高可維護性。而且若是在重構代碼時，強類型和靜態類型檢查會幫上大忙，必定程度上減小重構代價。（你們開發維護起來更安全、放心）。

• 線上運行質量

咱們如今的工具類項目不少bug都是因爲一些調用方和被調用方的數據格式不匹配引發的。TS能夠在編譯期進行靜態檢查，能夠在編寫調試代碼時就發現這些問題，而且IDE能夠智能糾錯，編碼時就能提早感知bug的存在，咱們的線上運行時質量會更爲穩定可控。

Flow、babel、tsc

flow用來作類型檢查，好比vue就是用的flow，可是flow也有不少問題：

• 無用的錯誤信息

好比 Incompatible instantiation for T， T 是一個類型變量，可是你並不能迅速找到這個錯誤在哪裏。

• 運行困難

運行 Flow是須要必定成本的。對於Mac 用戶來講很是幸運，經過 homebrew 能夠安裝預製的二進制包。但若是你須要本身編譯它，你就先得創建一套 OCaml 開發環境。

babel相比於tsc，首先定位是不一樣的，babel是一種js預處理工具，理論上說徹底能夠實現對ts的預處理，可是tsc對ts處理會更加精細。固然tsc 的功能沒有 babel 多，擴展性也沒有 babel 強。

項目的應用

咱們的開源腳手架builder-webpack4已經實踐了幾個月了，爲了更好的維護，咱們決定遷移到ts。這中間踩了一些坑，但也積累了一些經驗。

• tsconfig配置

ts配置文件有不少配置項，可是對於咱們開發node工具來講其實用到的並很少，咱們只須要關注模塊化，編譯路徑和輸出路徑便可。 關於模塊化，咱們但願輸出的是commonjs規範的，至於最終是es5/es6或是其餘，因人而異，咱們須要配置的就是：

"compilerOptions": {
    "module": "commonjs",
    "esModuleInterop": true,
    "target": "es5",
    "moduleResolution": "node"
	}
複製代碼

編譯路徑和輸出路徑，這裏跟webpack相似，固然這裏的編譯路徑是指定tsc編譯哪些目錄下的ts文件，不然編譯會由於內容太多而報錯。

"compilerOptions": {
    "outDir": "lib" //輸出路徑
  },
  //編譯目錄
  "include": [
    "src/**/*"
  ],
複製代碼

固然咱們還可能會指定types的路徑

"paths": {
      "*": [
        "node_modules/*",
        "src/types/*"
      ]
    }
複製代碼

• npm包的types

對於多數的npm包來講均可以經過安裝@types/xxx來解決，好比node咱們就能夠安裝@types/node，固然也有一些@types並無作管理，那就須要咱們本身來寫一下。舉個例子，webpack處理html相關會用到一個插件「html-webpack-plugin」，它是做爲一個模塊來使用，那麼只須要如下聲明便可

declare module 'html-webpack-plugin';
複製代碼

固然你可能會用到某些UMD的包（既能夠當模塊又能夠做爲全局變量使用）：

declare namespace UMD{
 	//能夠定義一些其餘東西
}
複製代碼

• interface（接口）

好比咱們有些方法須要修改一些參數，使用TypeScript 以後，把數據對應的 interface 改掉，而後從新編譯一次，把編譯失敗的地方所有改掉就行了。 對於builder-webpack4來講不少方法的參數都較爲複雜，好比咱們生成構建配置文件的時候，webpack的配置老多了，天然是須要寫個interface來控制，可是問題是若是別的模塊調用這個方法又得重寫一次？不用的，只要吧interface看成模塊同樣導出便可（固然你也能夠把這些寫到d.ts中，而後引入到對應的文件）。

export interface xxx{
    [propName: string]: any
}
複製代碼

• 靜態類型檢查

當咱們開始盲寫代碼的時候，總會不可避免的有些小失誤，那麼利用IDE配合ts提供的工具就能夠幫咱們提早發現一些問題；在編譯調試中一樣能夠發現一些未觸及的點。

咱們在調用方法的時候就知道這個方法須要哪些參數，固然若是類型寫錯了就立馬會有紅色波浪線標註出來（格外的扎眼）。

• 代碼質量的提高

做爲一種弱類型語言，js開發一些大型/持續維護項目的時候，常常會讓人體驗什麼是「開發一時爽，重構火葬場」。

• 其餘注意點

對於模塊的導出

export default builderWebpack4;
複製代碼

這個玩意編譯出來實際上是這樣子的

exports.default = builderWebpack4;
複製代碼

可是對於別的調用方來講並不能直接用，咱們想要的是

module.exports = builderWebpack4;
複製代碼

因此源碼中多加個指定就行了

module.exports = exports.default;
複製代碼

固然對於項目內部間模塊調用是不須要的，tsc構建會生成相關的hack

var __importDefault = (this && this.__importDefault) || function (mod) {
    return (mod && mod.__esModule) ? mod : { "default": mod };
};
Object.defineProperty(exports, "__esModule", { value: true });
var webpack_1 = __importDefault(require("webpack"));
複製代碼

何時須要用

• 大型項目

項目越大，越難以維護，所以對於多人寫協做的大型項目有必要使用ts來提升代碼質量。

• 持續維護的項目

對於一些長久運行的項目，既要保證它的穩定運行，又要保證項目交接便捷（可維護性），使用ts是目前來看最好選擇。

• 工具類項目

使用nodejs/js寫一些前端工具或者庫的時候，一樣是須要關注以上兩點內容，並且工具類的項目影響範圍較大，在開發維護中要更加謹慎，那麼使用ts幫咱們儘可能減小一些低級錯誤是頗有必要的。

---

關注公衆號：【IVWEB社區】，每週推送精品技術週刊 。

• 週刊文章集合: weekly
• 團隊開源項目: Feflow