[譯] 回顧 ESLint 的成功

• 原文地址：Reflections on ESLint's success
• 原文做者：Nicholas C. Zakas
• 譯文出自：掘金翻譯計劃
• 本文永久連接：github.com/xitu/gold-m…
• 譯者：薛定諤的貓
• 校對者：H2O-2、warcryDoggie

回顧 ESLint 的成功

難以置信，我在 2013 年 6 月構思開發了 ESLint，7 月第一次對外發布。熟悉的讀者可能還記得，ESLint 最初主要設計目標是運行時加載的檢查工具（linter）。在工做中我看到咱們的 JavaScript 代碼中的一些問題，但願能有一些自動化的手段避免這些問題再次出現。

在 ESLint 發佈後的 2 年半里，它的受歡迎程度大大增長。上個月的 30 天在 npm 上就有超過 1 500 000 次下載，這是當初平均月下載量只有 600 時我未曾想象的。

全部這一切發生了，然而過去 2 年我患上了很嚴重的萊姆病，幾乎沒法離開個人房子。這意味着我不可以外出參加會議和聚會來宣傳 ESLint（前 2 年我但是會議常客）。但不知爲什麼，ESLint 得到了普遍關注，而且繼續收到歡迎。我以爲是時候回顧其中原因了。

JavaScript 使用量增長

過去三年，咱們看到瀏覽器上 JavaScript 的使用量持續增長。根據 HTTP Archive[3]，如今網頁的 JavaScript 比 2013 年增長了 100 KB。

Chart - Increasing JavaScript Usage in Browsers 2013-2016

另外一個因素是 Node.js 的爆炸性流行。之前 JavaScript 僅限於客戶端使用，而 Node.js 使另一些開發者也可以使用 JavaScript。隨着運行環境拓展到了瀏覽器和服務器端，JavaScript 工具需求天然增長了。因爲 ESLint 能夠用於瀏覽器和 Node.js 上的 JavaScript，迎合了這一需求。

檢查工具更加流行

因爲 JavaScript 工具的需求增長，對 JavaScript 代碼檢查的需求也隨之增長。這很容易理解 -- 你編寫的 JavaScript 代碼越多，就越須要更多保障，避免一些常見錯誤。自 2013 年中以來 npm 上 JSHint、JSCS、ESLint 的下載量顯示了這一趨勢。

Chart - Increasing downloads for all JavaScript linters

JSCS 和 ESLint 幾乎是同時建立的，將它們各自的增長軌跡與更早一些的 JSHint 進行對比能夠看到一些頗有趣的地方。到 2016 年初，JSHint 在 JavaScript 代碼檢查領域有着優點地位，JSCS 和 ESLint 也在增加。最有趣的是這三個工具的下載量都在增加，說明每個月下載檢查工具的人多於更換的人數。

因此 ESLint 確實迎合了開發者對 JavaScript 代碼檢查需求增長的大趨勢。

ES6/Babel

在過去的四年裏，ECMAScript 6 的人氣一直在穩定增加，這也使 Babel 得到了極大成功。開發者不用等瀏覽器和 Node.js 的正式支持就可使用 ECMAScript 6 語法，這也須要 JavaScript 工具的新特性支持。在這一點上，JSHint 對 ECMAScript 6 特性支持不足，顯得有些落後了。

另外一方面，ESLint 有一個巨大的優點：你能夠用其它的 parser 來代替默認的 parser -- 只要它的輸出與 Esprima（或 Espree）兼容。這意味着你能夠直接使用 Facebook 的 Esprima 支持 ES6 的 fork （如今已再也不維護）來檢查你的 ES6 代碼。Espree 如今也已經支持 ES6 了（主要來自 Facebook 的 fork）。這使得開發者能夠很方便的使用 ES6。

固然，Babel 並無止步於支持 ES6 -- 它一樣也支持實驗特性。這就須要不但支持 ES 標準特性，還有其它開發中的特性（stage0 ~ stage4）。所以 ESLint 的 parser 可配置性就很重要了，由於 Babel 成員建立的 babel-eslint[4] 在其基礎上進行封裝，以便 ESLint 可以使用。

不久之後，ESLint 就成爲了使用 ES6 或者 Babel 的人推薦的檢查工具，這得益於容許兼容 parser 替換默認 parser 的設計決策。

如今，ESLint 安裝時大約有 41% 使用了 babel-eslint（基於 npm 下載量統計）。

React

討論 ESLint 的流行離不開 React。React 的一個核心特性就是支持在 JavaScript 中嵌入 JSX，而其它檢查工具起初都不支持這一特性。ESLint 不但在其默認 parser 支持 JSX，用戶也能夠經過配置使用 babel-eslint 或者 Facebook 的 Esprima fork 來支持 JSX。React 用戶也所以開始使用 ESLint。

咱們收到不少在 ESLint 自己加入一些 React 特有規則的請求，可是原則上我不但願有庫專有的規則 -- 由於這會帶來巨大的維護成本。2014 年 12 月，eslint-plugin-react[5] 引入了許多 React 專有規則，很快獲得了 Recat 開發者的歡迎。

後來在 2015 年 2 月，Dan Abramov 寫了一篇文章《Lint like it's 2015》[6]。這這篇文章中，他介紹了 ESLint 在 React 中的應用，並給出了高度評價：

若是你從未據說過 ESLint -- 它就是我一直想要 JSHint 成爲的那樣。

Dan 也介紹瞭如何配置使用 babel-eslint，提供了極有價值的文檔。明顯能夠看到這是 ESLint 的一個大的轉折點：月下載量從 2015 年 2 月的 89,000 到 2015 年 3 月的 161,000 -- 增加了近一倍。從這以後到如今，ESLint 經歷了一個快速增加的階段。

如今，eslint-plugin-react 在 ESLint 安裝中使用率有 45%+（基於 npm 下載量統計）。

可擴展性是關鍵

從一開始，個人想法就是 ESLint 自己是小核心工具，做爲大生態的中心。個人目標是經過容許足夠的擴展使 ESLint 永不過期：即使沒法提供的新特性，ESLint 仍然能夠經過擴展得到新功能。雖然如今 ESLint 尚未徹底知足個人設想，但已經很是靈活：

• 你能夠在運行時增長新規則，這使得任何人均可以編寫本身的規則。爲了不天天花費大量時間處理用戶想要各類預料外的規則，我將其視爲關鍵所在。如今，沒有什麼阻止用戶編寫本身的規則。
• parser 的可配置性使 ESLint 能夠處理任何和 Espree 兼容的格式。正如上文所述，這也是 ESLint 流行的一個重大緣由。
• 配置可分享，全部人均可以發佈和分享配置，很是便於不一樣的項目共用相同配置（ESLint 安裝中 eslint-config-airbnb 的使用率有 15%）。
• 插件系統 人們能夠很方便的經過 package 分享規則，文本處理器，環境和配置。
• 良好的 Node.js API 能夠很方便的用於構建工具插件（Grunt，Gulp等），也可用於建立零配置的檢查工具（Standard，XO等）。

我但願 ESLint 將來能夠提供更多的可擴展性。

聽取社區反饋

我很是努力作到的事情之一就是：聽取 ESLint 社區的反饋。雖然開始有些執拗於對於 ESLint 最初的設想，後來我意識到了衆人的智慧。聽到一樣的建議次數越多，就越有多是須要考慮的痛點。在這一點上我如今好多了，社區的不少好的想法也促成了 ESLint 的成功：

1. parser 可配置 - 直接來自 Facebook的建議，他們但願將 Esprima fork 用於 ESLint。
2. JSX 支持 - 起初我很是反對默認支持 JSX。但有持續不斷的建議，我最終贊成了。如上文提到的，這一點也成爲了 ESLint 成功的關鍵。
3. 可分享配置 - 來自 Standard 和其它基於 ESLint 的封裝，它們的目標是使用特定的配置來運行 ESLint。看起來社區確實須要一種簡便的方式來分享配置，所以這個特性誕生了。
4. 插件 - 起初加載自定義規則的惟一方式是，從文件系統使用命令行選項 --rulesdir 加載。很快人們開始在 npm 發佈本身的規則。這樣使用起來很痛苦，而且很難同時使用多個 package，所以咱們增長了插件以便可以方便的分享。

很明顯，ESLint 社區關於這個項目的成長有許多極好的想法。毫無疑問，ESLint 的成功直接受益於它們。

羣衆基礎

ESLint 發佈以來，我寫了兩篇相關文章。第一篇發表在個人我的博客，第二篇在去年 9 月發表於 Smashing 雜誌。除此以外，對 ESLint 的推廣僅限於 Twitter 和 管理 ESLint Twitter 帳戶。若是我願意花心思去作些演講的話，我確定會在推廣 ESLint 上作的更好。可是由於我沒有，我決定放棄嘗試去推廣它了。

然而我很欣喜的發現人們開始討論 ESLint，寫關於它的文章。起初是一些我不認識也沒據說過的人。不斷有人寫文章（好比說 Dan），人們也在各類會議和聚會上討論 ESlint。網上的內容愈來愈多，ESLint 很天然的也更加流行了。

一個有趣的對比是 JSCS 的成長。最開始 JSCS 獲得了 JSHint 的宣傳 -- JSHint 決定去除全部代碼風格相關的規則，而 JSCS 則做爲這些規則的替代品。所以當 JSCS 遇到問題時，會提到 JSHint 團隊成員。有了這個領域的巨頭支持，早期一段時間內，JSCS 的使用遠超於 ESLint。第一年的一段時間內，我曾一度覺得 JSCS 會碾壓 ESLint，讓我許多夜晚和週末的工做失去意義，然而這一切並無發生。

強大的羣衆基礎支持着 ESLint，最終幫助它獲得了巨大成長。用戶帶來了更多用戶，ESLint 也由此得到了成功。

關注實用性而非競爭

這是 ESLint 一路走來我最驕傲的事情之一。我歷來沒有說過 ESLint 優於其它工具，歷來沒有要求人們從 JSHint 或 JSCS 轉向 ESLint。我主要說明了 ESLint 能更好的支持你編寫自定義規則。到今天爲止，ESLint README 裏面這樣寫（在 FAQ）:

我不是說服你 ESLint 比 JSHint 更好。我只知道 ESLint 在個人工做中比 JSHint 更好。極小可能性你在作相似的工做，它可能更適合你。不然，繼續使用 JSHint，我固然不會勸說你放棄使用它。

這一直是個人立場，如今也是 ESLint 團隊的立場。一直以來，我始終認爲 JSHint 是很好的工具，它有着不少優點 -- JSCS 也同樣。不少人很是滿意於使用 JSHint 和 JSCS 這一對組合，對他們來講，我鼓勵他們繼續使用。

ESLint 關注於盡量有用，讓開發者來決定是否適合他們。全部決策都基於有用性，而非與其它工具競爭。這個世界能夠有不少檢查工具的空間，沒必要只有一個。

耐心

我之前說過[8]，如今開源項目間彷佛有一種不理性競爭：對人氣的關注高於一切。ESLint 是一個項目從誕生到成功的很好的例子。在項目誕生初的近 2 年裏，ESLint 的下載量遠低於 JSHint 和 JSCS。ESLint 和 社區的成熟都花費了時間。ESLint 的「一晚上成名」並非發生在一晚上，它經歷了持續不斷的基於有用性和社區反饋的改進。

優秀的團隊

我很幸運有很優秀的團隊爲 ESLint 作貢獻。因爲我沒有太多精力和時間在 ESLint 上，他們作了不少工做。一直令我吃驚的是我歷來沒有當面見過他們，也沒有聽過他們的聲音，但我很期待可以天天和他們對話。因爲我須要恢復健康，他們永恆的激情和創造力使得 ESLint 可以繼續成長。雖然我一我的開始了 ESLint 這個項目，但他們無疑是它可以發展達到目前的人氣的緣由。

很是感謝 Ilya Volodin, Brandon Mills, Gyandeep Singh, Mathias Schreck, Jamund Ferguson, Ian VanSchooten, Toru Nagashima, Burak Yiğit Kaya, 和 Alberto Rodríguez，謝謝大家的大量工做。

結論

有許多因素致使了 ESLint 的成功，我但願經過分享它們，能給其餘人建立成功的開源項目提供一個指引。最值得作的事情，一點幸運，其餘人的幫助和對要實現的東西的一個清晰的願景，這就是全部關鍵。我堅信若是你關注於創造一些有用的東西，願意付出辛苦的工做，最終將獲得應得的回報。

ESLint 也在繼續成長和改變，團隊和社區也是。期待 ESLint 的將來。

References

1. ESLint (eslint.org)
2. Introducing ESLint (nczonline.net)
3. HTTP Archive Trends 2013-2016 (httparchive.org)
4. babel-eslint (github.com)
5. eslint-plugin-react (github.com)
6. Lint like it's 2015 (medium.com)
7. ESLint: The Next Generation JavaScript Linter (smashingmagazine.com)
8. Why I'm not using your open source project (nczonline.net)

免責聲明：文中任何觀點都屬於 Nicholas C. Zakas 本人全部，不表明僱主、同事，Wrox Publishing、O'Reilly Publishing或其餘人。

---

【譯註】：本文發表於2016-2-9，如今 JSCS 團隊已經加入了 ESLint，文中有些數據也已經再也不準確，但文章關注點不在這些，因此再也不從新更新。但願這篇文章對開源做者有所參考！Enjoy it!❤️

---

掘金翻譯計劃 是一個翻譯優質互聯網技術文章的社區，文章來源爲 掘金 上的英文分享文章。內容覆蓋 Android、iOS、React、前端、後端、產品、設計 等領域，想要查看更多優質譯文請持續關注 掘金翻譯計劃。