在內(nèi)存安全中，類型安全是很重要的一個命題。為了確保JavaScript項目運行的類型安全，本文的作者介紹了2016年時使用Flow的經(jīng)歷：由Facebook支持的Flow方案，不僅擁有查找類型、泛型參數(shù)默認值等基本功能，還有著較為完善的JavaScript開發(fā)生態(tài)系統(tǒng)。但是隨著項目的不斷復(fù)雜，以及TypeScript功能的逐漸優(yōu)化，就對項目提出了更多的要求。本文就詳解了將三萬行代碼從Flow移植到TypeScript的全過程。

以下為譯文：

最近我們將MemSQL Studio的3萬行JavaScript代碼從Flow移植到了TypeScript。在本文中，我將介紹我們移植代碼庫的原因以及移植的全過程。

事先聲明，我寫這篇文章的目的不在于譴責(zé)Flow或Flow的使用。我非常欣賞Flow這個項目，我認為在JavaScript社區(qū)中Flow和TypeScript這兩種類型檢查器都有足夠的發(fā)展空間。但是，每個團隊都需要仔細研究并選擇最適合自己的。因此我真誠地希望這篇文章對你的選擇能有所幫助。

背景

首先介紹一下背景故事。在MemSQL，我們都喜歡靜態(tài)強類型的JavaScript代碼，這是為了避免動態(tài)弱類型的常見問題。例如：

動態(tài)弱類型問題中不同部分的代碼對于隱式類型契約的假設(shè)不一致，會引發(fā)運行時的類型錯誤；

而且動態(tài)弱類型在測試小問題上花費的時間太多，比如參數(shù)類型檢查（運行時類型檢查也會增大打包文件的尺寸）；

此外動態(tài)弱類型還缺乏編輯器/ IDE集成，因為在沒有靜態(tài)類型的情況下，很難實現(xiàn)跳轉(zhuǎn)定義、自動重構(gòu)以及其他功能；

靜態(tài)強類型還具有動態(tài)弱類型問題所缺失的圍繞數(shù)據(jù)寫代碼的能力，這意味著我們可以先設(shè)計數(shù)據(jù)類型，然后我們的代碼就會“自然成型”。

這些還只是靜態(tài)類型部分的優(yōu)點。

2016年初，我們開始在一個內(nèi)部的JavaScript項目上使用tcomb，以確保運行時的類型安全（聲明：我并沒有參與那個項目）。雖然有時運行時的類型檢查很有用，但它與靜態(tài)類型毫不沾邊。考慮到這一點，2016年的時候我們決定在另一個項目中使用Flow。當(dāng)時，F(xiàn)low是一個很好的選擇，因為：

Flow由Facebook支持，在日益壯大的React社區(qū)中收到了相當(dāng)多的好評（React也是用Flow開發(fā)的）；

我們沒有必要嘗試一個全新的JavaScript開發(fā)生態(tài)系統(tǒng)，拋棄Babel轉(zhuǎn)向tsc（TypeScript編譯器）的風(fēng)險會很大，還會失去切換到Flow或其他類型檢查器的靈活性（顯然后來情況發(fā)生了變化）；

我們也沒有必要在整個代碼庫上采用類型（因為我們想先嘗試一下靜態(tài)類型的JavaScript），我們只想在部分文件上采用類型（不過請注意，現(xiàn)在的Flow和TypeScript都允許開發(fā)者這么做）；

當(dāng)時的TypeScript缺少Flow支持的一些基本功能，例如查找類型、泛型參數(shù)默認值等。

當(dāng)2017年年末開始開發(fā)MemSQL Studio時，我們準(zhǔn)備在整個應(yīng)用程序中實現(xiàn)完整的類型覆蓋（整個應(yīng)用程序都是用JavaScript編寫的，前端和后端都在瀏覽器中運行）。因為以前成功使用的經(jīng)驗，所以我們決定此次也使用Flow。

然而，最新發(fā)布的Babel 7已經(jīng)開始支持TypeScript了，這引起了我的注意。這個發(fā)布意味著采用TypeScript不再需要引入整個TypeScript生態(tài)系統(tǒng)，我們可以繼續(xù)通過Babel來生成JavaScript。更重要的是，這意味著實際上我們可以將TypeScript作為類型檢查器，而不是作為一種“語言”。

就個人而言，我認為將類型檢查與JavaScript的生成分離是在JavaScript中實現(xiàn)靜態(tài)（強）類型的更優(yōu)雅的方式，因為：

將生成ES5和類型檢查從思想上進行某種程度的分離是一個好主意。如此一來可以減少類型檢查鎖定的范圍，并加快開發(fā)速度（即使類型檢查因某些原因而變慢，你的代碼生成也不會受到影響）。

Babel擁有一些非常優(yōu)秀的插件和了不起的功能，這些都是TypeScript的生成器所沒有的。例如，Babel允許開發(fā)者指定想要支持的瀏覽器，它將自動生成在這些瀏覽器上有效的代碼。不過這實現(xiàn)起來非常復(fù)雜，因此應(yīng)當(dāng)讓Babel做這一切，而不是讓社區(qū)在兩個不同項目上重復(fù)這種努力。

我喜歡JavaScript這種編程語言（除了它缺少靜態(tài)類型），我不知道TypeScript會最終存活多久，但我相信ECMAScript會長期存在。出于這個原因，我更喜歡用JavaScript思考和寫代碼。

注意，我一直在說“使用Flow”或“使用TypeScript”，是因為我總是把它們當(dāng)成工具，而非編程語言。

當(dāng)然，這種方法也有一些缺點：

理論上，TypeScript編譯器可以根據(jù)類型執(zhí)行優(yōu)化，但如果將生成與類型檢查分離就失去這個優(yōu)勢了；

如果需要依賴很多工具和開發(fā)，那么項目配置會變得稍復(fù)雜。不過我認為這個不足為慮，因為在我們的項目中Babel + Flow從來都沒出現(xiàn)過配置的問題。

TypeScript 能替代Flow 方案嗎？

我注意到網(wǎng)上和本地JavaScript社區(qū)對TypeScript的興趣越來越濃厚。因此，當(dāng)發(fā)現(xiàn)Babel 7支持TypeScript時，我就開始調(diào)查代替Flow的可能性。最重要的是，在使用Flow的時候我們遇到了很多挫折：

編輯器/ IDE集成的質(zhì)量很低（與TypeScript相比）。Nuclide（Facebook自己的IDE，擁有最好的Flow集成）已經(jīng)不再維護，所以沒什么用了。

社區(qū)很小。各種代碼庫數(shù)量較少，且總體的類型定義質(zhì)量較低。

Facebook和社區(qū)的Flow團隊之間缺乏公共的規(guī)劃，且互動很少。

內(nèi)存消耗很高且內(nèi)存泄漏頻繁，我們團隊的工程師偶爾會經(jīng)歷Flow占用10GB的RAM的現(xiàn)象。

當(dāng)然，我們還必須研究TypeScript是否合適我們。調(diào)查的過程非常復(fù)雜，但通過全面地閱讀文檔，我們發(fā)現(xiàn)Flow的每個功能在TypeScript中都有相應(yīng)的支持。之后，我又研究了TypeScript的項目規(guī)劃，發(fā)現(xiàn)上面提到的功能都有非常滿意的支持（例如，我們在Flow中使用的一個部分類型參數(shù)推斷的功能）。

將三萬多行代碼從 Flow 移植到 TypeScript

實際上，將所有代碼從Flow移植到TypeScript的第一步是將Babel從6升級到7。這項工作看似簡單，但由于我們決定將Webpack 3升級到4，所以最后花了兩天的時間。由于我們的代碼中有一些遺留的依賴，所以此次的難度要比絕大多數(shù)JavaScript項目都高。

完成這一步后，我們就可以用新的TypeScript預(yù)設(shè)替換Babel的Flow預(yù)設(shè)，然后在用Flow編寫的完整源代碼上運行TypeScript編譯器——結(jié)果發(fā)生了8245個語法錯誤（只有在沒有語法錯誤的情況下tsc的命令行工具才會報告項目中的真正的錯誤）。

我們被這個數(shù)字嚇到了，但是很快我們就發(fā)現(xiàn)其中大部分是由于TypeScript不支持.js文件導(dǎo)致的。經(jīng)過一番調(diào)查，我發(fā)現(xiàn)TypeScript文件必須以“.ts”或“.tsx”結(jié)尾（包含JSX的情況）。我不想在創(chuàng)建新文件的時候猶豫是應(yīng)該使用“.ts”還是“.tsx”的擴展名，因為這是一種糟糕的開發(fā)體驗。所以，我決定將所有文件都重命名為“.tsx”（理想情況下，應(yīng)當(dāng)像Flow一樣所有的文件都具有“.js”擴展名，但我也可以接受使用“.ts”）。

經(jīng)過這次修改后，我們有大約4000個語法錯誤。其中大多數(shù)都與導(dǎo)入類型有關(guān)，我們可以TypeScript的“import”替換，也可以使用Flow（{||} vs {}）中的密封對象表示法替換。在使用了幾個正則表達式替換之后，我們的語法錯誤數(shù)量降到了414個。剩下的部分只能手動修復(fù)了：

部分泛型類型參數(shù)推斷中使用的既存型別必須替換為顯式命名的各種類型的參數(shù)，或通過unknown類型告訴TypeScript我們并不關(guān)心某些類型的參數(shù)；

$Keys類型和其他Flow高級類型在TypeScript中具有不同的語法，例如，$Shape <>與TypeScript中的Partial<>對應(yīng)）。

修復(fù)了所有語法錯誤之后，tsc（TypeScript編譯器）終于告訴我們，代碼庫中大約有1300個真正的類型錯誤。這時我們不得不坐下商量是否還應(yīng)該繼續(xù)，畢竟，如果要花費數(shù)周的開發(fā)時間，此次移植就得不償失了。但是，我們發(fā)現(xiàn)只需花費不到1周的時間就可以完成移植，所以我們決定繼續(xù)。

注意，在轉(zhuǎn)換期間，我們必須停止代碼庫的開發(fā)工作。當(dāng)然，在移植期間依然可以繼續(xù)開發(fā)新代碼，但是你必須在可能有數(shù)百種之多的類型錯誤上進行工作，這不是一件易事。

都有哪些類型錯誤？

在很多方面，TypeScript和Flow都做出了不同的假設(shè)，在實踐中這意味著JavaScript代碼的行為會有所不同。在某些方面Flow更嚴(yán)格，而TypeScript在其他方面又更為嚴(yán)格。深入比較兩種類型檢查會花費大量時間，所以在本文中我只舉幾個例子。

注意：本文中所有的TypeScript練習(xí)環(huán)境（http://www.typescriptlang.org/play/）的鏈接都假設(shè)所有的“嚴(yán)格”設(shè)置都被打開了，但遺憾的是在分享TypeScript練習(xí)環(huán)境時，這些設(shè)置都不會保存到URL中。因此，可以點擊上面的連接打開TypeScript練習(xí)環(huán)境之后再手動設(shè)置。

invariant.js

我們的源代碼中有一個很常用的函數(shù)invariant，這個文檔（https://github.com/zertosh/invariant#invariantcondition-message）很好地解釋了它的功能：

varinvariant=require('invariant');invariant(someTruthyVal,'Thiswillnotthrow');//Noerrorsinvariant(someFalseyVal,'Thiswillthrowanerrorwiththismessage');//Errorraised:InvariantViolation:Thiswillthrowanerrorwiththismessage

這是個非常簡單的函數(shù)，它能在某些條件下拋出異常。下面讓我們來看看在Flow中它的實現(xiàn)與使用：

typeMaybe=T|void;functioninvariant(condition:boolean,message:string){if(!condition){thrownewError(message);}}functionf(x:Maybe,c:number){if(c>0){invariant(x!==undefined,"Whencispositive,xshouldneverbeundefined");(x+1);//worksbecausexhasbeenrefinedto"number"}}

下面，我們通過TypeScript運行完全相同的代碼片段。正如在鏈接中看到的那樣，TypeScript出錯了，因為它不清楚最后一行是否可以確保“x”不會被定義為undefined。這是一個眾所皆知的TypeScript的問題——它無法在函數(shù)中進行這類的推理。但是，由于這樣的代碼在我們代碼庫中很常見，所以我們就被迫手動替換每一個invariant的實例（有150多個）：

typeMaybe=T|void;functionf(x:Maybe,c:number){if(c>0){if(x===undefined){thrownewError("Whencispositive,xshouldneverbeundefined");}(x+1);//worksbecausexhasbeenrefinedto"number"}}

雖然這不如invariant那么好，但也不算大問題。

$ ExpectError vs @ ts-ignore

Flow有一個非常有趣的功能，類似于@ ts-ignore，不過不同的是如果下一行不是錯誤，那么它就會出錯。在編寫“類型測試”時，這個功能很有用。類型測試可以確保類型檢查（無論是TypeScript還是Flow）按照我們的期望找到某些類型錯誤。

不幸的是，TypeScript沒有這個功能，這意味著我們的類型測試失去了部分價值——這也是我期待TypeScript能夠?qū)崿F(xiàn)的功能。

一般的類型錯誤和類型推斷

通常，TypeScript會比Flow更清晰，如下例所示：

typeLeaf={host:string;port:number;type:"LEAF";};typeAggregator={host:string;port:number;type:"AGGREGATOR";}typeMemsqlNode=Leaf|Aggregator;functionf(leaves:Array,aggregators:Array):Array{//Thenextlineerrorsbecauseyoucannotconcataggregatorstoleaves.returnleaves.concat(aggregators);}

Flow推斷l(xiāng)eaves.concat(aggregators) 的類型為Array ，然后將其轉(zhuǎn)換為Array。我認為這是一個很好的例子，說明有的地方Flow很聰明，而TypeScript可能需要一點幫助（在這種情況下，我們可以用類型斷言來幫助TypeScript，但是類型斷言的使用很危險，請小心謹慎）。

盡管沒有正式的證據(jù)，但是我還是想說我認為在類型推斷方面Flow比TypeScript更優(yōu)越。我非常希望TypeScript能夠向Flow看齊， 因為TypeScript正處于非常積極的開發(fā)中，并且最近TypeScript有了許多改進。而縱觀我們的源代碼，我們必須通過解釋或類型斷言給予TypeScript一些幫助（還是盡可能地避免使用類型斷言）。讓我們再來看一個例子（我們有200多個這種類型錯誤的實例）：

typePlayer={name:string;age:number;position:"STRIKER"|"GOALKEEPER",};typeF=()=>Promise>;constf1:F=()=>{returnPromise.all([{name:"DavidGomes",age:23,position:"GOALKEEPER",},{name:"CristianoRonaldo",age:33,position:"STRIKER",}]);};

在TypeScript你不能這樣寫，因為它不允許你將{ name: "David Gomes", age: 23, type: "GOALKEEPER" }當(dāng)作Player類型的對象（打開練習(xí)環(huán)境可以看到確切的錯誤）。這是另一個我覺得TypeScript“不夠聰明”的地方——至少與Flow相比不夠聰明。

為了修正這個錯誤，開發(fā)者有幾個選擇：

斷言"STRIKER"為"STRIKER"，這樣TypeScript就可以理解該字符串是個有效的枚舉類型"STRIKER" | "GOALKEEPER"；

斷言整個對象為“Player”（as Player）；

或者（我認為的最佳解決方案）無需任何類型的斷言，只需寫Promise.all(...)。

另一個TypeScript的例子如下所示，這段代碼再次表明Flow具有更好的類型推斷：

typeConnection={id:number};declarefunctiongetConnection():Connection;functionresolveConnection(){returnnewPromise(resolve=>{returnresolve(getConnection());})}resolveConnection().then(conn=>{//TypeScripterrorsinthenextlinebecauseitdoesnotunderstand//thatconnisoftypeConnection.Wehavetomanuallyannotate//resolveConnectionasPromise.(conn.id);});

一個很小但非常有趣的例子是Flow判斷Array.pop()的類型為T，而TypeScript則認為它屬于T | void。這是我喜歡TypeScript的一個地方，因為它會強制你仔細檢查該項是否存在（如果數(shù)組為空，則Array.pop返回undefined）。

TypeScript對于第三方依賴的定義

當(dāng)然，在編寫任何JavaScript應(yīng)用程序時都有可能會有一些依賴。這些依賴都需要類型定義，否則開發(fā)者就失去了靜態(tài)類型分析的大部分威力（如本文開頭所述）。

從npm導(dǎo)入的庫可以附帶Flow類型定義或TypeScript類型定義，也可以兩者兼有或兩者都沒有。許多小型庫不帶有任何方式的類型，所以必須自己編寫類型定義，或從社區(qū)中找。Flow和TypeScript社區(qū)都有一個標(biāo)準(zhǔn)的JavaScript包的第三方類型定義代碼倉庫：flow-typed和DefinitelyTyped。

我不得不說使用DefinitelyTyped的體驗更好。在使用flow-typed的時候，我們必須通過它的命令行工具將各種依賴的類型定義引入到項目中。DefinitelyTyped找到了一個很好的方法與npm的命令行集成，即它的軟件包均以@types/package-name的方式命名。這一點非常了不起，有了它我們就可以很容易地為依賴引入類型定義了（jest、react、lodash、react-redux等等）。

除此之外，我花了大量時間向DefinitelyTyped貢獻代碼（當(dāng)將代碼從Flow移植到TypeScript時，不要指望類型定義是等價的）。我已經(jīng)發(fā)送了幾個拉取請求，所有工作都易如反掌。開發(fā)者只需要克隆、編輯類型定義、添加測試，然后發(fā)送拉取請求，DefinitelyTyped GitHub會將曾向這個類型定義貢獻過代碼的人標(biāo)記為審核者。如果7日之內(nèi)沒有人審核代碼，那么DefinitelyTyped的維護者會審核PR。在合并到master分支后，新版本的依賴包將會發(fā)送到npm。例如，當(dāng)我第一次更新@types/redux-form包時，在合并到master分支后版本7.4.14自動被推送到了npm。我們可以非常容易地更新package.json文件，就可以獲取新的類型定義。如果等不到PR被接受，那么也可以隨時覆蓋項目中使用的類型定義。

總的來說，DefinitelyTyped中類型定義的質(zhì)量更好，這要歸功于TypeScript背后的社區(qū)更大、更繁榮。事實上，在將我們的項目從Flow移植到TypeScript之后，我們的類型覆蓋率從88%提高到了96%，主要是由于更好的第三方依賴類型定義，“any”類型的依賴減少了。

Linting與測試

在移植過程中，我們發(fā)現(xiàn)使用TypeScript的eslint比較復(fù)雜，所以我們就選擇了tslint，從eslint轉(zhuǎn)移到了tslint。

此外，我們還使用ts-jest來運行TypeScript的測試。有些測試是有類型的，而有些是無類型的（如果給測試用例添加類型的工作量太大，我們就將它們保存成.js文件）。

修復(fù)了所有類型錯誤后，情況怎樣了？

經(jīng)過歷時一周的修復(fù)工作后，我們遇到了最后一個類型錯誤，我們決定利用@ts-ignore將其暫且擱置。

在解決了一些代碼審查注釋并修復(fù)了一些錯誤之后（不幸的是，我們不得不修改少量運行時來修復(fù)TypeScript無法理解的邏輯），在這個PR被合并后，我們就開始使用TypeScript了。（還有，我們在后續(xù)的PR中修復(fù)了最后一個@ts-ignore）。

除了編輯器集成之外，TypeScript的使用體驗與Flow非常相似。Flow服務(wù)器的性能稍微快一點，但這并不是一個大問題，因為在為你正在查看的文件提供內(nèi)聯(lián)錯誤時它們一樣快。唯一的性能差異在于TypeScript需要更長的時間（約0.5到1秒）才能告訴你在保存某個文件后，項目中是否有新的錯誤。服務(wù)器啟動時間大約相同（約2分鐘），但這并不重要。到目前為止，我們還沒遇到過內(nèi)存消耗的問題，tsc使用的內(nèi)存一直穩(wěn)定在大約600Mb。

可能看起來Flow的類型推斷比TypeScript更好，但是兩個原因可以解釋為什么這不是什么大問題：

我們將代碼庫從Flow移植到了TypeScript，這意味著我們在其中發(fā)現(xiàn)了Flow可以表達但TypeScript卻不能表達的地方。如果這次移植是從TypeScript到Flow的，那么我們可能就會發(fā)現(xiàn)TypeScript的推斷/表達比Flow更好。

類型推斷很重要，它有助于保持我們的代碼更簡潔。但是強大的社區(qū)、類型定義的可用性等更為重要，因為弱類型推斷只需要加強下類型檢查就可以解決。

代碼統(tǒng)計

$npmruntype-coverage#https://github.com/plantain-00/type-coverage43330/4504796.19%

$cloc#ignoringtestsanddependencies--------------------------------------------------------------------------------Languagefilesblankcommentcode--------------------------------------------------------------------------------TypeScript3305179140531463

下一步計劃？

雖然移植完成了，但是代碼中的靜態(tài)類型分析還沒有完成。

MemSQL還有其他項目也打算棄用Flow、轉(zhuǎn)而投入TypeScript的懷抱（有些JavaScript項目可能一開始就使用TypeScript），所以我們希望使我們的TypeScript配置更加嚴(yán)格。

目前我們已經(jīng)打開了“strictNullChecks”，但“noImplicitAny”仍處于禁用狀態(tài)，這也需要后續(xù)解決。

此外，我們還打算刪除代碼中的一些危險的類型斷言。