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

時間 2019-11-06

標籤大規模應用 typescript jsconf brie bunge 简体版

原文原文鏈接

特別說明

這是一個由 simviso 團隊對 JSConf.Hawaii 中關於大規模應用Typescript相關話題進行翻譯的文檔，內容並不是直譯，其中有一些是譯者自身的思考。分享者是Brie Bunge，Airbnb高級前端工程師。javascript

視頻地址：大規模應用TypeScript「2019 JSConf -Brie Bunge」前端

視頻翻譯文字版權歸 simviso 全部，微信公衆號：Simviso，未經受權嚴禁轉載java

本次參與翻譯人員react

前言

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

在大公司中進行大的改革很難。這須要去說服不少人，同時又須要涉及大量的代碼遷移。我想要與你們分享咱們是如何將 TypeScript 應用到 Airbnb這個公司的平常開發中的。我感謝大家能在這裏，我知道大家徹底能夠披着時髦的毛巾在海邊娛樂。程序員

我設想這裏的每一個人都會有這樣一些問題，你要爲你的公司進行重大的變革，同時這可能會被做爲一個案例進行研究，你如今是否在公司內部積極的推進將項目開發遷移到 TypeScript，爲此我將提供一些技術和工具上的幫助。github

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

首先，咱們會介紹 TypeScript 是什麼？規模化又意味着什麼？對於將Typescript規模化的過程又有什麼建議？基於這些問題和疑問，我會給出相應的解答，咱們該經過什麼樣的遷移策略將 JavaScript 逐步遷移到 TypeScript。編程

請你們快速舉手示意一下以方便我知道大概有多少人以前使用過 TypeScript， cool，有這麼多人。還有一部分人沒有舉手，那麼，讓咱們快速介紹一下，這樣每一個人都在同一塊兒跑線上了。後端

類型檢查

假如咱們有這麼一個 greeter 方法，它接收一個name參數，而後返回 "hello" + name。 So，若是咱們傳入的是"JSConf"，它會和睦的說"hello JSConf"。

將剛纔的代碼用 TypeScript 來表達就是這個樣子，能夠看到他們很像，惟一的區別是咱們在它的參數這裏使用了類型註釋，因此若是咱們在咱們的 TypeScript 項目中使用這個函數同時咱們傳入一個字符串，能夠看到編譯一切正常。

可是在這種狀況下，若是咱們傳遞的參數類型不是字符串，而是一個字符串數組，那麼 TypeScript，就會給咱們一個錯誤。即這是一個字符串數組，函數接收的參數類型是 string，不支持該分配。

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

咱們也能夠表達其餘對象類型。這個接口描述了一個包含名字和姓氏的 person對象。同時，你能夠定義更復雜的構造類型。 Typescript一般帶有一個編譯器，當出現問題時就能夠立馬告訴你。它還有一個能夠與編輯器掛鉤的語言服務器，能夠幫咱們進行自動編譯，提供重構相關提示等等

在這個例子中，咱們已經在這個組件中導入了withStyles react 來進行類型綁定。這樣就能夠自動導入它所須要的數百個CSS屬性，包括內聯文檔。

神奇吧！我不必來回瀏覽文檔頁面，我在編輯器中就能夠獲得這些全部。經過在咱們的代碼中使用類型，咱們能夠作更多的事情。

咱們只是稍微接觸了下TypeScript的類型限制，可是能夠經過這個來幫你捕獲這種類型的錯誤，以及支持它的工具。

關於TypeScript的類型檢查內容就到此，那關於規模化應用這一部分呢？

恩？這有個什麼問題？感謝Typescript幫我找出了這個錯誤。

若是你一時疏忽，輸入了一個錯誤的變量，那你將會獲得這樣的一個錯誤提示，so，在 TypeScript 中真的會發生這樣的事。因此，讓咱們來修復下。

規模化應用

規模化會改變咱們的交流方式。我之前在小團隊的時候，若是你想要使用TypeScript。是的，聽起來很酷，那咱們就用吧。

但當團隊規模達到數百位工程師，同時代碼量也愈來愈多，那麼交流方式就要發生改變。咱們須要進行一些改變，即當咱們想要在咱們的主倉庫中使用TypeScript的時候（這裏指Powers | airbnb.com的主倉庫），同時讓TypeScript成爲前端主要開發語言。這個改變影響的人越多，那麼必須遷移的代碼也就越多，那咱們用數字來講明規模化意味着什麼。

Airbnb（個人公司）擁有大量的JS代碼，在咱們的主倉庫中有兩百萬行以上的JS代碼，以及100多個內部NPM包。咱們有幾個分離的倉庫，經過打包到內部的NPM註冊中心，這樣就能夠跨倉庫共享。

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

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

這些數字給咱們展示了當時咱們提議要使用TypeScript時所面臨的大環境。那麼在這種規模下，咱們當時是一個什麼樣子呢？

每月，咱們都會將全部的前端工程師聚在一塊兒開個比較有意思的會，一塊兒討論新的前端技術和選型。爲了能夠作到深思遠慮，咱們起草了提案，它對某個新技術進行了諸如優勢、權衡、替代方案、針對退出方案的思考以及長期擁有者等方面概述。

你們會權衡這些提議的利弊，咱們會站在團隊的角度去決定向前邁出這步是否有意義。這確保了咱們能夠做爲一個集思廣益的團隊，對所作的事情作出深思熟慮的決定，這樣能夠避免在沒有正當技術理由的狀況下就「上車」。

從2016年起，Airbnb 已經在一些小規模團隊中探索使用 TypeScript。在2017年的前端調查中，靜態類型系統呼聲最高。基於這個信號，Joe（第二排那個Joe）和我起草了一個關於TypeScript的提案，並將它交給前端工做組。這項提案詳細說明了爲何在Airbnb使用TypeScript是有意義的。

讓我來說講主要的緣由。 airbnb的使命是要創建一個讓每個人都感覺到世界到處都是家（airbnb是一家旅遊住宿的公司），用戶對咱們的產品提出的每個建議都能會讓咱們向着這個目標更進一步，對於你正在開發的產品也是如此。

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

使用TypeScript，工程師能夠更安全快速的遷移代碼。在Airbnb咱們引入了GraphQL 和Apollo，它可使咱們經過自定義的GraphQL模板來生成TypeScript類型

這意味着咱們能夠獲得端到端之間的類型安全，由於前端和後端所使用的數據類型共享了同一個事實上的定義源，後端工程師可以在不影響客戶端的狀況下對API進行修改，而前端工程師則能夠確信哪些數據將從服務器返回。

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

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

咱們的主倉庫依賴了一些咱們內部的NPM包。爲了得到自動完成和類型檢查的能力，咱們須要先將它們轉換成TypeScript，這樣作是否值得？這也是咱們目前面臨的困境，咱們的TypeScript項目依賴於一個JS NPN包，那咱們該如何獲取這個包的類型？

彷佛須要先將包轉換爲 TypeScript。這看起來像是須要首先將這個包轉換爲TypeScript 但這裏有個問題，由於維護人員不容許咱們對它作TS轉換操做，可能他們也不情願這麼作。由於在咱們提案的早期，咱們並不肯定是否要一直按照這個提案走下去。

類型聲明文件

可是從另外一個層面來說，咱們使用TypeScript是爲了可讓開發人員能夠有更好的體驗。咱們須要TypeScript提供的類型安全性，那麼咱們該如何解決看似雞和蛋的問題呢？

TypeScript有一個叫作聲明文件的功能，即一個以.d.ts爲擴展名的文件，經過它咱們能夠爲JavaScript文件定義類型。

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

因此，讓咱們回到最初的場景，看看聲明文件是如何提供幫助的。那麼咱們回到咱們剛纔提的問題（要不要一開始就轉換），看看聲明文件是如何提供幫助的。固然，若是那個項目已轉換爲 TypeScript，咱們就沒有必要再生成一個.d.ts文件來做爲TypeScript構建時的一部分（由於在使用TS編程的時候，要經過它對生成的JS進行調用）。

但咱們認爲這不止一種選擇。相反，咱們能夠將聲明文件放在咱們的 TypeScript 項目中。另外一個選擇則是咱們能夠建立一個單獨的NPM包，並將全部聲明文件放入其中。這很棒，由於咱們如今能夠跨多個倉庫共享這些聲明文件。

DefinitelyTyped倉庫

這是如何在react使用類型。經過這些你能夠在使用相似React時，進行相應的類型檢查，在安裝React的同時你能夠安裝@types/react包

在這個 @types/react包中針對React的5000個經常使用包作了類型聲明, @types/react與其餘5000個其餘包都在 DefinitelyTyped 這個倉庫中，它由社區在維護

在咱們的主倉庫中，絕大多數的公共依賴都已經由DefinitelyTyped 作到了類型聲明，有活躍的社區氛圍是TypeScript 的一個主要賣點。咱們也回饋了一點力量，我相信在這個房間裏也有人作出了貢獻,謝謝。這些公共的NPM包的類型聲明已經有DefinitelyTyped在作了，但那些內部的包該怎麼辦?

咱們本身安裝了一個DefinitelyTyped鏡像，在它經過建立一個單獨的NPM域（ @airbnb-types/*），這樣，你只須要安裝 @airbnb-types便可倉庫的設置相似於類型的明確性。這個倉庫的設置與DefinitelyTyped相似因此咱們能夠在裏面添加併發布這些內部類型。咱們開源了一個starter 工具包，若是你又興趣的話，能夠來參與下。它裏面沒有類型定義，它只是在教你如何進行一些配置以便於進行測試或者發佈本身的類型定義。

那麼 TypeScript 究竟能幫忙避免多少 bugs 呢? 近期，一個叫作「該不應作類型定義」的研究代表，在選擇了TypeScript 的 github 倉庫中，有 15% 的 bugs 獲得了避免。在咱們內部，有一個記錄生產環境事故的流程。

這個流程的本意並非爲了責怪誰，而是要從錯誤中進行學習，這樣咱們以後就不會再犯相似的錯誤。因此我坐下來讀了六個月的總結報告。閱讀這些總結報告頗有意思，我最喜歡的就是未捕獲的異常以及危險的參數計算。好吧，也許這些錯誤的名字並無那麼使人激動。不管如何，我將這些錯誤歸類爲與 JavaScript 相關或無關，以此肯定哪些錯誤能夠經過使用Typescript 來避免

實例講解

讓咱們一塊兒看個例子，使用TypeScript會帶來哪些幫助咱們對所分享的這個 Input 組件進行修改，經過一些設置來還原bug。用戶沒法提交表單是由於它再也不能經過驗證。

這是所分享的 Input 組件更改前的簡化版本，它接收一個叫onBlur的變量，並將其直接傳遞給input元素。所作的改變就是添加一個新的onBlur 事件處理。

但這裏有一個不明顯的bug，你能發現它嗎？就是事件參數再也不傳遞給 onBlur prop。這就致使在好幾個不一樣倉庫中都出現了這同一個問題這裏 Input 組件做爲Redux Form的一部分進行使用，指望獲得一個事件或值，以便驗證正常工做。

若是沒有該事件，表單將再也不經過驗證，這就意味着提交按鈕始終處於禁用狀態。 TypeScript在這裏是如何幫到咱們的？

從文檔中咱們能夠看到Redux Form有類型捕獲約束， onBlur 事件屬性必須傳遞一個事件或值。

所以，若是咱們使用了TypeScript下的Redux Form，那麼在函數調用那裏就能夠看到一個當沒有傳遞事件參數時所產生的錯誤。

其餘特性

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

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

實際效果

那整體百分率是多少？（那個事故日誌所表現的）。

38%！

咱們發現有38%的事故致使了生產階段的bug。這些對咱們用戶產生實際影響的bug，可使用TypeScript來阻止。這對咱們來講是個巨大的發現。它有助於實現影響。它有助於將這種（積極）效果轉換到現實中。咱們複製了一些BUG事件，並向你們展現了TypeScript所給出的Error提示，而後對bug進行修復（也就是咱們看到的bug提示燈泡滅掉了）

的確，咱們也能夠經過寫測試代碼來捕捉這些，可是經過靜態類型檢查能夠額外增長一層保護層。所以，若是你所在公司有相似的歷史，那麼你可能就有必要和懂Typescript小夥伴一塊兒來看一下這些問題在大家的代碼裏所佔的比例。

團隊構建

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

在用了一段時間後，咱們向他們發送了一份調查問卷，詢問他們是否應繼續使用Typescript。反饋結果是很是確定的。咱們建議使用這種試用期（的形式，其實就是金絲雀模式）來測試新技術或模式。前端工做組的開發也是基於這個形式來進行的，由於它是獨立的，它能夠很容易回滾到以前的狀態。這也對提案頗有幫助，由於咱們能夠判斷團隊是否真的喜歡使用Typescript。

這裏可能會有一些關於構建時間上的擔心，咱們測量了，發現並無明顯的影響。

咱們在主倉庫啓用超過了500條eslint規則，也使用typescript eslint解析器，咱們很高興地發現它們中的大多數均可以工做。若是咱們在未來要棄用Typescript的話，咱們能夠剝離類型，並最終獲得大體相同的JavaScript。

因此咱們逐一記錄、思考、跟進，而且針對提出的問題和擔心找到解決辦法。與批評者合做並聽取他們的擔心對咱們來講很是重要。最後這些批評者中的大部分轉而會支持咱們，咱們的提案也從他們的反饋中變得更爲健壯。

在充分解決了這些問題以後，針對全部前端工程師進行了咱們是否應該採用Typescript的調查。咱們收到了確定的回答以後，咱們有足夠的證據向前推動，並經過這項提案。

漸進遷移

在此基礎上，咱們逐步擴大了採用範圍此時，咱們已經度過了試驗階段，這對於驗證 typescript 和打好基礎是頗有用的。

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

咱們一直與 typescript 團隊保持着持續聯繫，並幫忙解決一些問題，好比，更好的默認屬性優先級處理。

在這個階段，咱們本身內部的 typescript 社區也獲得了發展。可是大部分 Airbnb 的員工還不知道 typescript，這也意味着更多的人能夠去幫助和回答他們的問題。接下來咱們將會進入測試狀態，團隊能夠選擇使用它。爲了幫助團隊，咱們建立了內部文檔和風格指南，並舉辦了一些學習課程。

咱們創建了一個聊天組，一個內部的類Stack Overflow，谷歌Email主題，github組，來供組內成員交流。咱們想確保人們能獲得他們須要的幫助，最後一步是將 typescript 徹底普及化。此時就意味着它是穩定狀態，每一個人都應該開始使用它，咱們目前正在努力地去接近這個目標。剩下的步驟就是鞏固風格指南、文檔、增強內部培訓和遷移更多代碼。到目前爲止，咱們大約有50%的團隊使用 typescript，在主倉庫中，有10%的文件已經被轉換成 typescript 經過這種漸進的方法，使團隊遷移至 typescript 的過程更加順暢。若是從第一天開始就要求每一個人應該使用TypeScript，那麼接下來的每一個人都會遇到一樣的問題。相反，咱們先在小範圍內使用 typescript ，而後總結一些經驗技巧，當咱們準備把它大規模推廣時，這些經驗技巧也會用得上。

遷移策略

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

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

咱們添加了一個typescript配置文件，並將各個文件從js重命名爲ts或jsx重命名爲tsx。 typescript報錯了，那咱們動手去修復他們吧。 typescript 的一個很棒的特性是，在編譯和運行以前，並不須要轉換全部代碼。這個配置選項（allowJS）容許 javascript 和 typescript 文件共存，在這一點上，咱們能夠看到網站仍能繼續運行。咱們不須要暫停開發而去遷移整個項目，咱們能夠一步步來，咱們能夠挨個遷移文件。咱們會重複這個過程，直到整個項目被遷移。

遷移技巧

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

第一個是 $TSFixMe，咱們經過TypeScript的any類型添加了一個全局類型別名，這意味着它能夠爲任何類型。咱們將它稱之爲$TSFixedMe，代表在代碼向TypeScript遷移完成後，再來將類型修正平時最佳實踐是避免使用 any，由於它會形成類型安全丟失，但它在遷移過程當中會頗有幫助。

使用 @ts-ignore註解能夠作到忽略下一行錯誤。正確地輸入一個文件可能涉及一些深層依賴鏈解析（相似於複雜對象）。咱們能夠嘗試經過首先轉換子文件來避免這種狀況，但有時這是不可避免的。所以，$TSFixedMe和@ts-ignore註解可以幫助拆分這些內容，同時則會增長這些檢查工做。這些都是暫時的，咱們計劃添加類型覆蓋工具，並在後面咱們改進類型時提供幫助

在JSX中，咱們在React組件上使用propTypes 進行運行時類型檢查。在將jsx轉換爲tsx的時候，咱們能夠刪除proptypes直接用typescript,也能夠在proptypes基礎上添加typescript 在咱們所分享的react項目中，咱們想保留傳參類型，以便別人使用的時候仍然能夠得到運行時檢查。

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

這樣， propTypes和 defaultProps組合並獲得這個最終類型。若是你好奇它是如何工做的，你能夠查看我在gist上分享的代碼片斷。

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

咱們從js形式的文件開始，咱們把全部的文件都改爲TS形式的。而後讓項目編譯，可能咱們使用一些比咱們想要的更寬鬆的類型。但其實咱們已經開啓了TS最嚴格的檢查配置。而後咱們接下來再繼續改進類型，移除ts fix語句，好比@ts-ignore（@ts-ignore 註釋隱藏 .ts 文件中的錯誤），這與js和ts混合策略相比起來有一些優點。

經過類型逐步改進比經過文件逐步改進更爲簡單（兩種策略的對比），若是你正在開發一個新功能，你只須要關注新添加的類型，而後簡單的修復這個它便可。而不是先轉換整個文件來修復全部錯誤，而後再添加你所須要類型。不用重命名文件也意味着更方便查看。有時候，若是一個文件在一次提交被重命名，而後在別的提交中修改。他們會在code review中單獨出現，程序員必需要合在一塊兒看才能知道變化了什麼，後一種策略還能清楚地知道缺乏哪些類型。 TypeScript類型推導能力十分強大，咱們能夠在編寫代碼的時候大量使用它。

爲了經過編譯，有些文件須要進行一些TS Fixed， ts就能夠推斷出剩餘部分。

還有就是開發者們可能有一個固定的思惟模式，他們並不會根據文件擴展名來切換思惟，因而就出現了好比爲何我不能在這裏添加類型，爲何我不能在那裏獲得編譯錯誤的疑問（js和ts混用）。那些類型在全部文件中均可以添加、使用、檢查。

大型項目遷移策略

這聽起來很不錯，可是咱們該如何遷移咱們整個代碼呢？對於大規模代碼修改而言，Codemod是一種十分強大的工具。拿最簡單的形式來講，就比如是咱們在咱們的項目中所使用的全局搜索和替換。你也許在你以前的IDE裏面幹過這件事(全局查找和替換)，這些Codemod庫能夠經過正則來替換。但它們很不穩定，可能會因細微的代碼風格變化而終止。

或者咱們可使用以前某人已經講過的抽象語法樹， so，這就是這段代碼用AST（抽象語法樹）來表達的形式。如圖所示，左側的代碼都一一對應着右側抽象語法樹上的節點，因此爲了好玩，咱們想寫一個Codemod來反轉代碼中的全部標識符。

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

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

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

咱們找到與標識符對應的全部節點，用名字反轉，用新節點去替換這些節點，而後獲得新的代碼。 Missy Elliott（歌手）也將會咱們感到自豪，因此咱們反轉了它。你們笑了，很棒！我在演講就像Joy Division作的那樣，咱們拿到了代碼而且從新改裝，找到了成員的標識符而後翻轉它。yeah！ astexplorer.net這個網站沒法幫你掌握好說唱技巧，但能夠幫助你查看你的Codemods。

在這個網頁下，它有一個能夠經過源代碼輸出對應的AST樹的功能，以及在你對代碼的改變同時反映到AST樹上。我也在DefinitelyTyped 這個庫提交了關於Jscodeshift的pr，這樣的話能夠來下降你們在使用TypeScript與Codemod的交互門檻，

遷移模式

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

對於react組件，咱們一次次的將靜態類屬性移動到class body裏面。建立一個PropsType表示react生命週期方法。咱們將它們編碼爲Codemod，以便咱們能夠在更多代碼上重複運行它們。咱們經過使用一個叫做TS Migrate的工具來將它們進行打包，這個工具的功能是傳入一個JS項目，而後獲得一個編譯好的ts項目。

隨着時間的推移，你仍然須要慢慢找到類型，但它爲你提供了一個工做前提。咱們將此工具應用於咱們的內部分享的React組件庫，如今在咱們的網站上已經頻繁地使用。咱們有內部的類型定義庫（DefinitelyTyped），可是由於react分享組件庫的快速發展，因此作到與時俱進地更新太難了，因此，咱們想直接從源碼類型出發。因此這是咱們遷移TS的第一個目標。

咱們已經將超過3萬行以上的代碼都進行了TypeScript化。大家可能認爲咱們整個團隊花了四周的時間才能完成這個。事實上，咱們用了一套咱們本身的Codemod工具，僅需數分鐘就完成了。咱們使用來自proptypes的類型信息，同時使用$TSFixMe，並基於此來繼續進行優化，但即使如此，咱們也生成了有意義的TypeScript聲明文件，這樣咱們能夠在其餘倉庫中進行使用。

在這個例子中，咱們能夠看到須要合併的代碼行數多的有點可怕，經過使用TypeScript編譯器以及在可視化迴歸測試的幫助下，咱們將在CI上運行測試。經過這些測試我能夠很自信的說，個人這些改變不會對原來的系統產生任何不利的影響，固然咱們還能確保咱們的站點仍舊在正常工做。並不須要回滾代碼，難以想象。咱們如今已經將TS Migrate運用在其它的一些地方，同時也在不斷優化和迭代它。咱們計劃在之後會將它運用於更多的代碼上(JS代碼)，咱們打算以後將它開源，這樣大家也能將它運用在大家的本身的代碼遷移上。

心得感想

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

在大型組織中實施變革多是一項挑戰，但強有力的事實依據和相關問題和擔心的解決，可使咱們信服。採用逐步變化的方式有助於減小摩擦並證實其價值。一條明確的遷移路線能幫助團隊更好的轉向新的模式，同時好的工具也能促進這個過渡的過程，我之因此開始這個工做，是由於以前有個產品組對個人工具感到失望。當我得知公司內部其餘人也有這種改變的想法的時候，我便與他們合做並將之進行下去。