這個雷踩了四次，為什麼你可能需要 Eslint
以一個簡單到不行的大小寫為例
這個 Bug 從第一次找了兩天，到現在 2017 年開發又碰到了，不過很幸運的，這次只花幾分鐘就找到了。直接來看以下這個 React Component 引用的例子有沒有什麼問題：
// components/buttonComponent.js
export const buttonComponent = () => <button>Button</button>;// containers/App.js
import ButtonComponent from '../components/ButtonComponent';
Question for you：這樣使用方法有沒有問題？
Answer for you：可能會，也可能不會。
在前端工程師必備的 Mac OS 環境下完全不會有問題，但是一旦把這個 Code 丟到 CI 上面跑，例如 Travis CI 用的是 Linux 環境，那問題就大了。
差別在於 Filesystem 的 Case-semantic。如果你有注意到的話，Filename buttonComponent.js 與引用的 ButtonComponent 不一致，雖然在 Mac 的環境會查詢到這個檔名，但是在 Linux 環境則是 Case sensitive，因此就會噴錯。事實上在 Webpack Build 的過程就已經偷偷地警告過你：
因為只是 Warning 層級，在 CI 依然會顯示綠勾勾 ✅，一旦你打開頁面才會發現竟然出了狀況，而且要在 Log 海中要找到這個訊息，機會實在是很渺茫。
不單只是 Coding Style 或命名規範，你可能會需要 Eslint 來幫你盡量降低這種小意外的發生。
讓我們來看一下 Eslint 套件中的 import/no-unresolved，這個規則主要是用來檢查你引用的檔案存不存在，設定上還有一個預設的值是 caseSensitive: true，如此就能順便檢查大小寫了，以下這個範例就會出現 Error：
透過 CI 設定甚至能讓你在事前就能發現它。另外在 Editor 上設定也能在平時開發就能避免掉，簡直舉手之勞而已：
當然這只是 Eslint Rules 上百條中的其中一個，可以參考筆者的另一篇文章做 Eslint 與 Prettier 的導入喔！
