「2019 JSConf.Hawaii - Brie.Bunge」大規模應用 TypeScript

特別說明

這是一個由 simviso 團隊對 JSConf.Hawaii 中關於 TypeScript 相關話題進行翻譯的文檔，內容並不是直譯，其中有一些是筆者自身的思考。分享者爲 Brie.Bunge，Airbnb（愛彼迎）高級前端工程師。

現以下，TypeScript 已然興起，若是各位小夥伴大家公司還未將開發遷移到 TypeScript 下，亦或正在遷移或者已經遷移了，那麼不妨一塊兒透過本文來看看 Airbnb 是如何作到大規模應用 TypeScript 的。

視頻地址：

• 「2019 JSConf.Hawaii - Brie.Bunge」大規模應用 TypeScript

視頻翻譯版權歸 simviso 全部，未經許可嚴禁轉載

前端公衆號

1、前言

你們好，個人名字是 Bree，在 Airbnb 工做。

在大公司中進行大的改革很難，這須要去說服不少人，同時又須要涉及大量的代碼遷移。

我想要和你們分享的是，咱們是如何將 TypeScript 應用到 Airbnb 的。

我感謝大家能在這裏，我知道大家徹底能夠披着時髦的毛巾在海邊娛樂。

但我但願你們都能從中受益，不管你是否正在爲你的公司進行重大改革，這均可以做爲一種案例進行研究。不管你如今是否正在積極的進行 TypeScript 遷移，咱們都將討論一些能夠幫到你的工具和技術。

或許，你已經聽過一些 TypeScript 的內容，但想了解更多。

首先，咱們會介紹 TypeScript 是什麼？規劃化又意味着什麼？提議使用 TypeScript 的過程又是如何？

基於這些問題和疑問，我會給出相應的解答。咱們該經過什麼樣的遷移策略將 JavaScript 逐步遷移到 TypeScript。

請你們快速舉手示意一下以方便我知道大概有多少人以前使用過 TypeScript。酷，有這麼多人。

還有一部分人沒有舉手。那麼，讓咱們快速介紹一下，這樣每一個人都在同一塊兒跑線上了。

2、快速介紹

假如咱們有這麼一個 greeter 方法，它接收一個 name 參數，而後返回 'Hello' + name。

因此，若是咱們傳入的是 JSConf，它會和睦的說 Hello JSConf。

將剛纔的代碼用 TypeScript 來表達就是這個樣子。

能夠看到它們很像，惟一的區別是咱們在它的參數這裏使用了類型註釋。

因此若是咱們在咱們的 TypeScript 項目中使用這個函數同時咱們傳入一個字符串，能夠看到編譯一切正常。

可是在下圖的狀況下，若是咱們傳遞的參數類型不是字符串，而是一個字符串數組，那麼 TypeScript 就會給咱們一個報錯，即字符串數組不能分配給 string 類型的參數。

咱們不須要再經過點擊刷新頁面這一流程來從咱們的控制檯中查看錯誤並肯定該錯誤所發生的位置。能夠看到，在咱們輸入後，當即就從編輯器中獲得了這個錯誤。

咱們也能夠表達其餘對象類型，具體如圖

這個接口描述了一個包含名字和姓氏的 person 對象。同時，你能夠定義更復雜的構造類型。

TypeScript 一般帶有一個編譯器，當出現問題時就能夠立馬告訴你。它還有一個能夠與編輯器掛鉤的語言服務器，能夠幫咱們進行自動編譯，提供重構相關提示等等。

再看個例子，如圖

例子中，咱們已經將咱們的 React 高階組件 withStyles 進行了類型綁定。因此它能夠自動對數百個 CSS 屬性進行聯想，包括內聯文檔。

牛逼吧！這樣一來我就沒必要再來回翻閱文檔頁面了，我在編輯器中就能獲得全部屬性。

經過使用 TypeScript，咱們在編碼時能作更多的事情。

這僅涉及了 TypeScript 很是基礎的一些功能，但卻讓你瞭解到它捕獲類型錯誤的能力，以及支持它的工具。

3、規模化應用

關於 TypeScript 是什麼的內容就到此，那關於規模化應用這一部分呢？

一、具體規模場景

規模化會改變咱們的交流方式。

之前我在小團隊的時候，在那若是你想用 TypeScript。「是的，聽起來很酷，那咱們用吧。」

但當你的團隊規模達到數百位工程師、同時代碼量也愈來愈多時，交流方式則會發生改變。

咱們將進行改革，咱們提議在咱們的主倉庫中使用 TypeScript，並讓它成爲前端開發的主要語言。

改革影響的人越多，那必須遷移的代碼也越多。

讓咱們來量化一下咱們所說的規模。如圖

Airbnb 擁有大量的 JS 代碼，咱們的主倉庫中有超過 200W 行的 JS 代碼，以及 100 多個內部 npm 包。

這些都是分離的倉庫，經過打包到內部的 npm 註冊中心的，這樣就能跨倉庫共享了。

這真的有不少代碼，我甚至能看到一些 Backbone 的影子。能夠想下 JavaScript 走過了多少年，它在 Airbnb 這也走過了十年之久，因此咱們也有大量的開發在維護這些代碼。

目前公司有超過 1300 名的開發，其中有 200 個是前端，這些前端工程師大多數都參與了主倉庫的貢獻。

這些數字描繪了咱們當時提議使用 TypeScript 所面臨的困境。

那麼，它在如此規模下咱們須要作什麼呢？

每月，咱們都會舉行一次有趣的會議，公司全部前端工程師都會聚在一塊兒，一塊兒討論新的前端技術和模式。

爲了能夠作到深思遠慮，咱們起草了份提案，它概述了諸如優勢、權衡、替代方案、棄用策略以及長期擁有者等事項。

你們會權衡這些提議的利弊，咱們會站在團隊的角度去決定向前邁出這步是否有意義。

這確保了咱們能夠做爲一個集思廣益的團隊，對所作的事情作出深思熟慮的決定，避免在沒有正當技術理由的狀況下就「上車」了。

從 2016 年起，Airbnb 已經在一些小規模團隊中探索使用 TypeScript。

在 2017 年的前端調查中，靜態類型系統的呼聲最高。

基於這些，Joe 和我起草了一個關於 TypeScript 的提案，並將它交給前端工做組，這項提案詳細說明了爲何在 Airbnb 使用 TypeScript 是有意義的。

讓我來說講主要的緣由。

Airbnb 的使命是：

讓每一個人在哪都有歸屬感

用戶每遇到的一個問題均可能致使咱們背道而馳，對於你正在開發的產品也是如此，而TypeScript 能夠幫助咱們減小 bug 的發生。

TypeScript 還爲開發人員提供大量的生產力效益和工具，像咱們以前看到，自動編譯和重構。

使用 TypeScript，工程師能夠更安全快速的遷移代碼。在 Airbnb，咱們引入了 GraphQL 和 Apollo ，它容許咱們在 GraphQL 模式中直接生成 TS 聲明。

這意味着咱們能保證端到端的類型類型，由於先後端本質上使用的數據類型共享了同一申明。後端工程師可以在不影響客戶端的狀況下對 API 進行修改，而前端工程師則能夠明確哪些數據將從服務器返回。

類型不匹配一直是咱們的主要 bug 所在。所以，這種端到端的類型安全性是一個主要的賣點。

這聽起來很棒，但對於咱們的初步提案，還有不少問題和疑慮。讓咱們更深刻地瞭解其中的一些。

咱們的 mono repo（譯者注：mono repo 意爲代碼都在一個倉庫）是依賴咱們內部 npm 包的。

爲了得到自動完成和類型檢查，咱們須要先將它們轉換爲 TypeScript 嗎？

這就是咱們面臨的困境，咱們的 TypeScript 項目依賴 JS npm 包，咱們如何拿到那些包的類型定義？

這彷佛的確須要先將那些包轉換成 TypeScript。

但這有個問題，因爲維護人員不容許咱們對它轉換，或許他們不肯這麼作吧。由於在咱們提案的早期階段，咱們也不肯定是否能繼續推動下去。

但從另外一方面來說，使用 TypeScript 是爲了讓開發人員在有一個更好的開發體驗，咱們須要 TypeScript 提供的類型安全性。

那麼咱們該如何解決這個看似雞和蛋的問題呢？

二、解決方案 - 申明文件

TypeScript 有一個稱爲聲明文件的特性，即擴展名爲 .d.ts 的文件，咱們能夠爲 JavaScript 文件定義類型。

讓咱們來看一個例子，繼續拿咱們前面提到的 greeter 方法來作說明，如圖

它上面是對應的.d.ts文件。方法裏沒有實現細節，它只描述了類型。TypeScript 將它們組合到一塊兒，這樣，編譯時使用的是這個聲明文件，而運行時使用的則是這個原生的 JS 文件。

因此，讓咱們回到剛纔咱們提到的問題（要不要一開始就作轉換），看看聲明文件是如何提供幫助的。

固然，若是這個項目已經轉換成 TypeScript 了，那麼則不必再去生成一個 .d.ts 文件來做爲 TypeScript 構建時的一部分了。

但我認爲這不止一種選擇，相反，咱們能夠將聲明文件放在咱們的 TypeScript 項目中。

另外一個選擇則是，咱們能夠建立一個分離的 npm 包，將申明文件丟到那。

這很好，由於如今咱們能夠跨倉庫共享聲明文件。

這就比如 @types/react 中的類型定義。你安裝 react 的同時，你也能夠安裝 @types/react 做爲其類型定義的包。

@types/react 是 DefinitelyTyped 5000 多個包中的一個，它由一個社區專門進行維護。

咱們主庫中絕大多數的公共依賴都在 DefinitelyTyped 中定義了。

TypeScript 社區活躍也是它的一大賣點。咱們也回饋了一些力量，我相信在座的各位也作過貢獻，謝謝啦。

公共 npm 包已經有 DefinitelyTyped 作定義了，但那些內部包該怎麼辦呢？

咱們經過建立一個獨立的 npm 做用域對 DefinitelyTyped 作了一個內部鏡像，因此當你 install @types/* 時，其實是 install @airbnb-types/* 的。

這個倉庫的設置跟 DefinitelyTyped 差很少，因此咱們能在那加上本身的類型定義，而後在內部發布。

咱們開源了一個入門的工具包（types-starter），若是你對這些設置感興趣能夠看下。它裏面沒有任何類型定義，它只教你如何配置，以便你測試併發布本身的類型定義。

那麼，TypeScript 究竟能幫忙避免多少 bug 呢？咱們看張圖

近期，一個叫作 「該不應作類型定義」 的研究代表，在選擇 TypeScript 的 github 倉庫中，有 15% 的 bug 獲得了避免。

在咱們內部，有個記錄生產環境事故的流程。這個流程的本意並非爲了責怪誰，而是要從錯誤中進行學習，這樣咱們以後就不會再犯相似的錯誤。

因此我坐下來讀了六個月的總結報告，看這些報告頗有意思，其中我最喜歡看到的莫過於 未捕獲的異常、危險的參數計算 等。

好吧，或許這些報錯的名字沒有讓人那麼激動。

不管如何，我將這些錯誤歸類爲與 JavaScript 相關或無關，以此肯定哪些錯誤能夠經過使用 TypeScript 來避免。

4、案例講解

讓咱們一塊兒看個例子，看看使用 TypeScript 能帶來哪些幫助。

一、參數傳遞

咱們對共享組件 Input 作些修改，經過一些設置來還原 bug，用戶沒法提交表單是由於它再也不經過驗證。

組件 Input 的更改前的簡化版本具體如圖

它接收一個 onBlur 變量，並將其直接傳遞給 input 元素。所作的改變就是添加一個新的 onBlur 事件處理。

但這存在一個不明顯的bug，你能發現它嗎？就是事件參數再也不傳遞給 onBlur 事件屬性。

這就致使了在好幾個倉庫中都出現了這同一個問題。Input 組件做爲 Redux Form 的一部分使用，指望傳遞參數是 event 或 value，以便驗證正常工做。

若是沒有該參數，表單將再也不經過驗證，這就意味着提交按鈕始終處於禁用狀態。

TypeScript 在這是如何幫到咱們的呢？

咱們從文檔中能夠看到 Redux Form 有類型約束，onBlur 事件屬性必須傳遞一個 event 或 value 類型參數。所以，若是咱們使用了作了 TS 申明的 Redux Form，那麼在函數調用那則能夠看到一個不傳遞事件參數的報錯。具體如圖

二、其它特性

另外一類常見的問題就是涉及嚴格的空值檢查，即便用屬性來構造或嘗試調用可能爲 null 或 undefined 的內容。你可能之前有見過這個錯誤，如圖

另外一種是類型不匹配。當咱們嘗試使用彼此不匹配的類型時，TypeScript 就會提示咱們。 因此如今咱們對常見的檢查出來的問題有了更好的理解，TypeScript 能夠幫助預防這種 bug。

三、日誌數據

那事故日誌中表現出來的整體百分比是多少呢？

38%！

咱們發現有 38% 的事故致使了生產階段的bug。

這些對咱們用戶產生實際影響的 bug，可使用 TypeScript 來阻止，這對咱們來講是個巨大的發現。

它有助於作案例復現。以前，咱們複製了一些 bug 事件，並向你們展現了 TypeScript 所給出的 error 提示，而後對 bug 進行修復。

的確，咱們能經過寫測試案例來捕獲這些，但經過靜態類型檢查則能夠再額外加一層保護。

所以，若是你所在的公司也有相似的歷史，那你可能就有必要和那些玩過 TypeScript 的小夥伴一塊兒看看我說起的這些問題在大家代碼中所佔比例了。

四、團隊推動

那麼團隊是否但願切換到 TypesSript 呢？咱們在幾個團隊試用了 TypeScript，專門針對以前沒有使用過 TypeScript 的團隊來獲取更多的使用反饋。咱們幫他們設置好 TypeScript 環境，而後收集他們的反饋。

在用了一段時間後，咱們向他們發送了一份調查問卷，詢問他們是否應該繼續使用 TypeScript？

從上圖能看出，答案是很是確定的。

咱們建議使用金絲雀模式來測試新技術或模式，前端工做組的開發也是基於這種形式來進行的。因爲它是獨立的，因此它很容易就能回滾到以前的版本。

這樣對提案也頗有幫助，由於咱們能夠判斷團隊是否真的喜歡使用 TypeScript。

固然，可能還會有一些別的擔心。

• 構建時間如何？

關於構建時間上的擔憂，咱們測過了，發現並無明顯的影響。

• eslint rule 如何處理？

在咱們主倉庫中啓用了超過 500 條的 eslint 規則，配合 @typescript-eslint/parser 使用。

• 棄用策略如何？

咱們很高興的發現它們中的大多數都能工做，因此若是咱們未來咱們要棄用 TypeScript 的話，咱們能夠剝離類型，最後獲得大體相同的 JS 代碼。

因此咱們逐一記錄、思考、跟進，而且針對提出的問題和擔心找到解決方法。與質疑的人合做並聽取他們的意見對咱們來講很是重要。

最後這些質疑的人大部分都轉向來支持咱們，咱們的提案也由於他們的反饋變得更加健壯。

在充分解決了這些問題以後，針對全部前端工程師咱們又作了份《咱們是否應該採用 TypeScript？》的調查。結果如圖

在收到確定的回答後，咱們有足夠的證據向前推動，並經過這項提案。

5、漸進式遷移

在此基礎上，咱們逐步擴大了採用範圍。

此時，咱們已經度過了 Pilot 試驗階段，這對於驗證 TypeScript 和打好基礎是頗有用的。

咱們已經解決了早期的矛盾，並改進了工具和文檔，因此以後的團隊成員會更容易入門。

咱們一直都與使用 TypeScript 的團隊保持着聯繫，並幫助他們解決一些問題，好比更好的默認屬性優先級處理。

在這個階段，咱們內部的 TypeScript 社區也獲得了發展，但大部分 Airbnb 的員工還不知道 TypeScript，這意味着更多的人能夠去幫助和回答他們的問題。

接下來，咱們會進入到 Beta 測試狀態。

團隊能夠選擇使用它，爲了幫助團隊，咱們建立了內部文檔和風格指南，並舉辦了一些學習課程。

咱們建了一些聊天組，內部的 Stack Overflow 組、谷歌 Email 主題小組、GitHub 組等，供組內成員交流，咱們想確保人們能獲得他們須要的幫助。

最後一步是將 TypeScript 徹底普及化。

此時就意味着它是穩定狀態，每一個人都應該開始使用它， 咱們目前正在努力地去接近這個目標。

剩下的步驟就是鞏固風格指南、文檔、增強內部培訓和遷移更多代碼。

到目前爲止，咱們大約有 50% 的團隊使用 TypeScript，在主倉庫中，有 10% 的文件已經被轉換成 TypeScript。經過這種漸進的方法，使團隊遷移至 TypeScript 的過程更加順暢。

若是從第一天開始就要求每一個人應該使用 TypeScript， 那麼接下來的每一個人都會遇到一樣的問題。

相反，咱們先在小範圍內使用 TypeScript ，而後總結一些經驗技巧，當咱們進行大規模推廣時，這些經驗技巧也會用得上。

6、遷移策略

咱們已經探索出了幾種將代碼遷移至 TypeScript 的方式。

一、混合使用

咱們最初的遷移策略的是混合使用 JS/TS。

讓咱們來看看，在主倉庫中這個策略是如何進行的。

這是我在 airbnb.com 上找到的一個簡化版本，而且給它們起了一個比較合理的名字， 因此這裏不存在公司的隱私信息。 讓咱們放大 homes 項目，看看使用混合策略轉換它會是什麼樣子。

咱們添加了一個 TypeScript 配置文件，並將各個文件從 js 重命名爲 ts，或 jsx 重命名爲 tsx。

TypeScript 報錯了，那咱們動手去修復他們吧。

TypeScript 的一個很棒的特性是，在編譯和運行以前，並不須要轉換全部代碼。這個配置選項（allowJS）容許 JS 和 TS 文件共存，在這一點上，咱們能夠看到網站仍能繼續運行。

咱們不須要暫停開發而去遷移整個項目，咱們能夠一步步來，咱們能夠挨個遷移文件。咱們會重複這個過程，直到整個項目被遷移。

二、遷移技巧

在關於遷移的話題上，我想花些時間和你們分享一些咱們認爲有用的技巧。

• any 大法

第一個是 $TSFixMe，咱們經過 TypeScript 的 any 類型添加了一個全局類型別名，這意味着它能夠爲任何類型。

咱們將它稱之爲 $TSFixedMe，代表在代碼向 TypeScript 遷移完成後，再來將類型修正。

平時最佳實踐是避免使用 any，由於它會形成類型安全丟失，但它在遷移過程當中會頗有幫助。

• @ts-ignore 註釋

使用 @ts-ignore 註解能夠作到忽略下一行錯誤。

正確地輸入一個文件可能涉及一些深層依賴鏈解析 — 相似於複雜對象。

咱們能夠嘗試經過首先轉換子文件來避免這種狀況，但有時這是不可避免的。

所以，$TSFixedMe 和 @ts-ignore 註釋可以幫助拆分這些內容，同時則會增長這些檢查工做。

這些都是暫時的，咱們計劃添加類型覆蓋工具，在咱們後面作類型改進時提供幫助。

• 類型組合

在 JSX 中，咱們在 React 組件上使用 propTypes 進行運行時類型檢查。

在將 jsx 轉換爲 tsx 的時候，咱們能夠刪除 propTypes 直接用 TypeScript,也能夠在 propTypes 基礎上添加 TypeScript。

在咱們所分享的 React 項目中，咱們想保留傳參類型，以便別人使用的時候仍然能夠得到運行時檢查。

爲了不重複兩次類型聲明，那就須要與這些類型保持同步。咱們建立了一個 Props 類型，經過它將給定的 propTypes 和 defaultProps 來派生出一個 TypeScript 類型。

這樣，propTypes 和 defaultProps 組合並獲得這個最終類型，如圖

若是你好奇它是如何工做的，你能夠查看我在 git 上分享的 代碼片斷。

三、All-in TS 策略

最近咱們已經在使用 修訂遷移策略 All-in TS 進行實驗, 讓咱們回過來再看看這個 homes 項目，而後對它們進行使用 All-in 策略，而後在看它工做怎麼樣。

咱們從 JS 形式的文件開始，咱們把全部的文件都改爲TS形式的。

而後讓項目編譯，可能咱們使用一些比咱們想要的更寬鬆的類型，但其實咱們已經開啓了TS最嚴格的檢查配置。

而後咱們接下來再繼續改進類型，移除 $TSFixedMe 以及 @ts-ignore 語句，這與 JS/TS 混合策略相比起來有一些優點。

經過類型逐步改進比經過文件逐步改進更爲簡單（兩種策略的對比）。

若是你正在開發一個新功能，你只須要關注新添加的類型，而後簡單的修復這個它便可。而不是先轉換整個文件來修復全部錯誤，而後再添加你所須要類型。

不用重命名文件也意味着更方便查看。

有時候，若是一個文件在一次提交時被重命名，而後在別的提交中修改。他們會在 code review 中單獨出現，程序員必需要合在一塊兒看才能知道變化了什麼。

後一種策略還能清楚地知道缺乏哪些類型。

TypeScript 類型推導能力十分強大，咱們能夠在編寫代碼的時候大量使用它。爲了經過編譯，有些文件須要對 TS 作一些調整，TS 就能夠推斷出剩餘部分。

還有就是開發者們可能有一個固定的思惟模式，他們並不會根據文件擴展名來切換思惟。

因而就出現了：爲何我不能在這裏添加類型？爲何我不能在那裏獲得編譯錯誤的疑問（JS/TS 混用）？之類的問題。 那些類型在全部文件中均可以添加、使用、檢查。

四、大型項目遷移策略（AST）

譯者注：若是有小夥伴想更多的瞭解 AST，能夠參考我以前的文章《AST 與前段工程化實戰》

上面的方案聽起來都很不錯，可是咱們該如何遷移咱們整個代碼呢？

對於大規模代碼修改而言，Codemods 是一種十分強大的工具。

拿最簡單的形式來講，就比如是咱們在咱們的項目中所使用的全局搜索和替換，你也許在你以前的 IDE 裏面幹過這件事

這些 Codemod 庫能夠經過正則來替換，但它們很不穩定，可能會因細微的代碼風格變化而終止。

或者咱們可使用以前某人已經講過的抽象語法樹。

這就是這段代碼用 AST 來表達的形式。從上圖能看到，左側的代碼都一一對應着右側抽象語法樹上的節點，因此爲了好玩，咱們想寫一個 Codemod 來反轉代碼中的全部標識符。

咱們將咱們的代碼做爲輸入參數， 根據這個建立出 AST， 修改 AST 而後產生新的代碼。

這裏的關鍵是咱們以編程方式進行此更改。若是你手上須要修改的文件數並很少的話，咱們能夠一個個的去修改， 但若是一旦文件數量達到數千個以上，這種手動去修改的想法可能會使人感到十分心累。

所以咱們 Airbnb 採用了 Facebook 的 jscodeshift 來進行這種大量的代碼重構，這個轉換庫能夠捕獲咱們剛剛對該 AST 進行的修改而且反轉標識符。

咱們找到與標識符對應的全部節點，用名字反轉，用新節點去替換這些節點，而後獲得新的代碼。如圖

Missy Elliott（歌手）也將會咱們感到自豪，因此咱們反轉了它。你們笑了，很棒！

我在演講就像 Joy Division 作的那樣，咱們拿到了代碼而且從新改裝，找到了成員的標識符而後翻轉它。（這段分享者直接現場唱起了 Rap，手動扣 6）

AST explorer 這個網站沒法幫你掌握好說唱技巧，但能夠幫助你查看你的 Codemods。

在這個網頁下，它有一個能夠經過源代碼輸出對應的 AST 的功能，以及在你對代碼的改變同時反映到AST樹上。

我也在 DefinitelyTyped 提交了關於 jscodeshift 的 PR，這樣的話能夠來下降你們在使用 TypeScript 與 Codemod 的交互門檻。

五、方案總結

在將 JavaScript 代碼遷移到 TypeScript 時，有這幾種模式。

對於 React 組件，咱們一次次的將靜態類屬性移動到 class body裏面。建立一個 PropsType 表示 React 生命週期方法。

咱們將它們編碼爲Codemod，以便咱們能夠在更多代碼上重複運行它們。

咱們經過使用一個叫做 TS Migrate 的工具來將它們進行打包，這個工具的功能是傳入一個 JS 項目，而後獲得一個編譯好的 TS 項目。

隨着時間的推移，你仍然須要慢慢找到類型，但它爲你提供了一個工做前提。

咱們將此工具應用於咱們的內部公共的 React 組件庫，如今在咱們的網站上已經頻繁地使用。

咱們有內部的類型定義庫（DefinitelyTyped），可是由於 React 公共組件庫的快速發展，因此作到與時俱進地更新太難了，因此，咱們想直接從源碼類型出發，這也是咱們遷移 TS 的第一個目標。

咱們已經將超過 3W 行以上的代碼都作了 TypeScript 化。

大家可能認爲咱們整個團隊花了四周的時間才能完成這個。事實上，咱們用了一套咱們本身的 Codemod 工具，僅需數分鐘就完成了。

咱們使用來自 propTypes 的類型信息，同時使用 $TSFixMe，並基於此來繼續進行優化。

但即使如此，咱們也生成了有意義的 TS 聲明文件，這樣咱們能夠在其餘倉庫中進行使用。

在這個例子中，咱們能夠看到須要合併的代碼行數多的有點可怕。

經過使用TypeScript編譯器以及在可視化迴歸測試的幫助下，咱們將在 CI 上運行測試。

經過這些測試我能夠很自信的說，個人這些改變不會對原來的系統產生任何不利的影響，固然咱們還能確保咱們的站點仍舊在正常工做。並不須要回滾代碼，難以想象吧。

咱們如今已經將 TS Migrate 運用在其它的一些地方，同時也在不斷優化和迭代它。咱們計劃在之後會將它運用於更多的 JS 代碼上。

咱們打算以後將它開源，這樣大家也能將它運用在大家的本身的代碼遷移上。

7、總結

感謝大家聽我講了這麼久， 我想給你一些咱們能夠從 TypeScript 遷移中得出關鍵點，而且是能夠普遍應用的。

在大型組織中實施變革多是一項挑戰，但強有力的事實依據和相關問題和擔心的解決，可使咱們信服。

採用逐步變化的方式有助於減小摩擦並證實其價值。

一條明確的遷移路線能幫助團隊更好的轉向新的模式，同時好的工具也能促進這個過渡的過程。

我之因此開始這個工做，是由於以前有個產品組對個人工具感到失望。當我得知公司內部其餘人也有這種改變的想法的時候，我便與他們合做並將之進行下去。

與其怨天尤人不如接受現狀，只有經過行動才能發生積極的改變。

因此我鼓勵你去追求那些可讓你對組織充滿激情的事情，讓你和你周圍的人的生活變得更好。

感謝你們的傾聽，同時感謝 AirBnb 爲這個項目做出貢獻的每個人，尤爲是臺下的 Joe 和 Mohsen。還有對其餘一些優秀的 Airbnb 工程師表示感謝。

感謝你們的傾聽。