[譯] 自定義 Babel 和 ESLint 插件是如何提升生產率與用戶體驗的

時間 2019-11-17

標籤自定義 babel eslint 插件如何提升生產率用戶體驗简体版

原文原文鏈接

原文地址：How writing custom Babel & ESLint plugins can increase productivity & improve user experience

原文做者：Kent C. Dodds

譯文出自：掘金翻譯計劃

本文永久連接：github.com/xitu/gold-m…

譯者：H2O2

校對者：MJingv，zyziyun

自定義 Babel 和 ESLint 插件是如何提升生產率與用戶體驗的

一個正在探索森林的人（來源：unsplash.com/photos/ZDhL…）javascript

自定義 Babel 和 ESLint 插件是如何提升生產率與用戶體驗的

並且比你想象的容易不少...html

個人前端大師課程「程序變換（code transformation）與抽象語法樹（AST）」已經發布了🎉 🎊（進入網址查看課程的簡介）！我以爲大家應該都有興趣瞭解爲何要花上 3 小時 42 分鐘來學習編寫 Babel 和 ESLint 插件前端

構建應用程序是件困難的事，而且難度會隨着團隊和代碼庫的擴張而增大。幸運的是，咱們有諸如 ESLint 和 Babel 這樣的工具來幫助咱們處理這些逐漸成長的代碼庫，防止 bug 的產生並遷移代碼，從而讓咱們能夠把注意力集中在應用程序的特定領域上。java

ESLint 和 Babel 都有活躍的插件社區 (現在在 npm 上「ESLint plugin」能夠搜索出 857 個包，「Babel Plugin」則能夠搜索出 1781 個包)。正確應用這些插件能夠提高你的開發體驗並提升代碼庫的代碼質量。react

儘管 Babel 和 ESLint 都擁有很棒的社區，你每每會遇到其餘人都沒遇到過的問題，所以你須要的特定用途的插件也可能不存在。另外，在大型項目的代碼重構過程時，一個自定義的 babel 插件比查找/替換正則要有效得多。android

你能夠編寫自定義 ESLint 和 Babel 插件來知足特定需求webpack

應在何時寫自定義的 ESLint 插件

ESLint logoios

你應該確保修復過的 bug 再也不出現。與其經過測試驅動開發（test driven development）達到這個目的，先問問本身：「這個 bug 是否是能夠經過使用一個類型檢查系統（如 Flow）來避免？」若是答案是否認的，再問本身「這個 bug 是否是能夠經過使用自定義 ESLint 插件來避免？」這兩個工具的好處是能夠靜態分析你的代碼。git

經過 ESLint 你 不須要運行任何一部分代碼便可判定是否有問題。github

除了上面所說的以外，一旦你添加了一個 ESLint 插件，問題不只在代碼庫的特定位置獲得瞭解決，該問題在任何一個位置都不會出現了。這是件大好事！（並且這是測試沒法作到的）。

下面是我在 PayPal 的團隊使用的一些自定義規則，以防止咱們發佈曾經出現過的 bug。

確保咱們一直使用本地化庫而不是把內容寫在行內。
強制使用正確的 React 受控組件（controlled component）行爲並確保每一個 value 都有一個 onChange handler。
確保 <button> 標籤老是有 type 屬性。
確保 <Link> 組件和 <a> 標籤老是有合理的 data 屬性以解析數據。
確保只在某個應用或共享文件夾內部導入文件（咱們在一個倉庫（repo）裏有多個應用）。

咱們還有更多的規則，但總的來講規則並很少。很讚的一點是，由於咱們花了時間去學習並編寫自定義 ESLint 插件, 這些 bug 都沒有再次出現。

注意：若是某個 bug 沒法經過 Flow 或 ESLint 避免，那多是業務邏輯出了什麼問題，你能夠回到經過測試的方式來避免此類狀況發生（學習如何測試 JavaScript 項目）。

應在何時寫自定義的 Babel 插件

Babel logo

若是你在思索：「那個 API 實在太無趣了」或是「咱們不能那麼作，運行效率過低。」那你就應該考慮寫一個自定義的 babel 插件了。

Babel 插件容許你調整代碼。這一操做既能夠在編譯時完成（以此來進行一些編譯時的優化），也能夠是一個一次性的操做（稱爲「codemod」，你能夠把它想象成一種比正則表達式強得多的查找替換功能）。

我很喜歡 Babel 的一個緣由：

Babel 使咱們能夠同時提高用戶和開發者的體驗。

下面的例子說明了 babel 插件是如何作到的這一點的。

在登錄界面就加載整個應用十分浪費資源，所以社區採起了「code-splitting」來避免這種狀況。react-loadable則實現了 React 組件的延遲加載。若是你想實現更復雜的功能（如服務器端支持或優化客戶端加載），就須要相對複雜的 API 了，然而，babel-plugin-import-inspector 已經自動爲你處理好這一切了。
Lodash 是一個使用很普遍的 JavaScript 實用程序庫，但同時它也很大。一個小竅門是，若是你「cherry-pick」須要用到的方法（好比：import get from 'lodash/get'），只有你用到的那部分代碼會被最終打包。babel-plugin-lodash 插件會讓你正常使用整個庫（import _ from 'lodash'）而後自動 cherry-pick 所需的方法。
我在構建 glamorous.rocks 網站（即將上線）時發現，不管用戶使用的哪一種語言，全部本地化字符串都會被加載！因此我寫了一個自定義的 babel 插件基於 LOCALE 環境變量加載正確的本地化字符串。這樣咱們就能夠爲每種語言建立一個服務端渲染網站的靜態輸出，並開始在服務器端爲本地化字符串使用 markdown 了（而咱們以前會在 JavaScript 模塊裏使用 markdown 的字符串，徹底是一團亂）。咱們能夠再也不使用使人混亂的「高階組件（Higher Ordered Component）」來進行本地化，而能夠在服務器上導入 markdown 文件。最終網站變得更快且對開發者更友好了。

還有不少例子，不過但願這些已經足夠讓你認識到自定義 Babel 插件所帶來的可能性了。

哦對了，你知道那些隨着框架和工具主要更新一塊兒推出的 codemods 嗎？它們會像施魔法同樣 ✨ 把你的代碼更新到最新的API（好比 React 的這個 codemod 或者 webpack 的這個 codemod）。你能夠把那些工具寫成 babel 插件而後經過 babel-codemod 運行（看看這個 babel-codemod 的演示）。（經過這篇演講深刻了解 codemods，演講者 Chirstoph）。

我無論你的正則表達式用得有多好，自定義 babel 插件可讓你作得更好。

可是到底什麼是 AST？我可不是什麼火箭專家 🚀 ！

astexplorer.net 上一個名爲「你也許不須要 jQuery」的 babel 插件演示。打開連接：kcd.im/asteymnnj
Babel 和 ESLint 都以一個名爲抽象語法樹（Abstract Syntax Tree，常縮寫爲 AST）的結構爲基礎運行。實際上這就是計算機如何讀取代碼的。Babel 有一個名爲「babylon」的 JavaScript 語法分析器，能夠把代碼字符串變成一個 AST（其實就是一個 JavaScript 對象），而後 Babel 把一些片斷提供給 babel 插件來讓你操做。若是是 Babel 則你能夠作一些變形，若是是 ESLint 則你能夠檢查你不但願出現的規則。

我沒有計算機科學的文憑。我一年前纔開始學習 AST。