技術標籤：筆記javascripteslint

JS作為一門動態型別的語言，在給開發者帶來便利的同時，也不可避免的引起一些潛在問題。簡單來說，它需要你在程式設計的時候充分的瞭解當前物件是否有你要使用的方法或者屬性。

然後人腦畢竟是有限的。所以就需要一些手段幫你找到潛在的問題。這種手段分為兩種：

• 型別檢查，也即是TypeScript做的事
• 問題（problem）檢查，eslint做的事

舉個例子，下面的程式碼展示了二者對各自認為有問題的地方做出提示。

// TS 報錯 This expression is not callable.
// 但eslint則認為OK
const anVar = "my var"
 
;
anVar();

// 下面的情況可能在演算法中比較常見。
// 對於eslint而言，這種程式碼可能引起潛在的問題。
// 但對TS來說，是被允許的。
while (foo -= 2) { // no-cond-assign
  console.log(foo)
}

但其實二者沒有特別明確的邊界。事實上，二者對多數潛在的錯誤都會做出提示，比如：

// TS: Duplicate function implementation
// ESLINT: Identifier 'bar' has already been declared
function bar() {
//
}
function bar() {
//
}
 

只不過eslint的規則是可擴充套件的，且非常豐富的，對於使用了TS的專案，如果有需要也可以使用eslint。

有點跑題了，在我們初始化eslint的時候，會有幾個選項供我們選擇。

$ npx eslint --init

這個意思是說，你想使用eslint做哪些事：

• syntax 語法檢查，這個eslint即使什麼也不配置，也預設支援的。畢竟如果你的程式碼本身有語法問題，是根本跑不通的。但我們一般感受不到，因為IDE已經幫你做了這件事了。除非你使用記事本之類的去開發。最後你可能會執行npx eslint somefile.js。所以如果我們使用eslint，就不可能只選擇第一個的功能。
• syntax and find problems 該選項會幫你新增推薦的規則，如上文所示的no-cond-assign即不允許在條件判斷中賦值。這些可以認為是潛在的問題
• syntax，find problems, and enforce code style。這個選項是除了上邊第二條的以外，還包括程式碼風格的檢查。

選擇程式碼風格

實際上，程式碼風格與潛在的問題邊界也不是那麼清晰，尤其是一組規則內的配置，比如airbnb的規則，可能即包含潛在的問題，也可能包括程式碼風格，比如：

function myfunc(params) {
  params = 'not ok in eslint'
}
// 上邊的程式碼如果使用了airbnb有兩個錯誤
// 1. ssignment to function parameter 'params' 不允許重新給引數賦值
// 2. Missing semicolon 缺少分號

如上，兩個錯誤中，顯然第一個是潛在的問題。第二個才是程式碼風格。

簡單總結下：

• TS與eslint的功能並非重合的，eslint的可擴充套件可能定製更多的團隊規範
• 為了保證團隊程式碼風格的統一，有必要是用eslint。
• TS，eslint質量檢查，eslint風格檢查，（其實prettier更擅長風格檢查）他們並非有嚴格的邊界。我們可以同時使用。