Npmjs.org 有數(shù)十萬個包,但它們的質(zhì)量不盡相同。檢查直接依賴項的管理情況很重要。如果功能是正確的,那么任何一個缺失的管理實踐都不應該從您的考慮中排除一個包,但是當你可以選擇包時,選擇管理良好的包或者準備好自己維護包!
我用來評估項目的一種做法是 JavaScript linting。
為什么要對 JavaScript 進行 lint?
運行良好的項目具有清晰、一致的編碼約定,并具有自動執(zhí)行功能。當我審查一個項目時,它的代碼看起來像一個孩子用斧頭和房子的圖片建造的房子,它并沒有激發(fā)代碼功能的信心。
沒有編碼約定也是吸引貢獻的障礙。依賴于一個不歡迎貢獻的項目本身就是一種風險。
除了檢查樣式之外,linter 也是查找某些類型錯誤(例如與變量范圍相關(guān)的錯誤)的絕佳工具。分配給未聲明的變量(這些會泄漏到全局范圍,污染它并可能導致很難找到錯誤)和使用未定義的變量是在 lint 時可檢測到的錯誤示例。
如何配置 ESLint
ESLint 是用于 linting Node.js 包的主要工具,可以配置為強制執(zhí)行多種編碼風格??梢远x自己的樣式定義,但在這里我將展示如何使用 StrongLoop 樣式。還有其他的,但是StrongLoop的風格平淡無奇(好東西,編碼風格不應該引起注意),和很多開源Node.js項目中使用的類似。
- 安裝并保存軟件包依賴項:?
npm install --save-dev eslint eslint-config-strongloop
?. - 通過運行設(shè)置 ESLint 以使用 StrongLoop 配置?
echo '{"extends": "strongloop"}' > .eslintrc.json
?。 - 確保你有一個.gitignore文件(因此派生文件不會被 linted,只有原始源文件)。如果你沒有,你可以用最少的努力創(chuàng)建一個:?
echo node_modules/ >> .gitignore
?.請注意,也可以使用特定于 ESLint 的.eslintignore文件,該文件與 .gitignore 具有相同的語法,并且可能具有相同的內(nèi)容。為了避免這種維護負擔,大多數(shù)項目只使用 .gitignore。 - 使用此設(shè)置,通過將 package.json 更改為pretest腳本,將 ESLint 配置為在測試之前自動運行。它應該類似于:
- 提交 ESLint 自動化支持:
- 完成后,運行
{ ...
"scripts":
{
"pretest": "eslint --ignore-path .gitignore ."
} ...
}
package.json 的確切內(nèi)容取決于您的項目。你必須添加預測試腳本以使 ESLint 在你的單元測試之前運行。當你使用 npm 運行測試腳本時,它還會運行 pretest 和 posttest 腳本(如果存在)。我更喜歡這個,因為 eslint 通常比我的測試運行得快得多,而且 lint 錯誤很容易修復,但有些人更喜歡在 linter 之前運行整個測試套件,在這種情況下,使用 posttest。
git add package.json .gitignore .eslintrc.json
git commit -m 'Add eslint automation
linter: npm run pretest
如果你的控制臺充斥著大量錯誤,請不要氣餒!
如何讓現(xiàn)有代碼清理干凈
人們避免使用 ESLint 的一個原因是清理從未被 lint 的代碼感覺就像清理Augean 馬廄。我建議像 Hercules 那樣做:從工具中獲取幫助。
- ESLint 可以自動修復許多語法問題。這應該是你用來清理源代碼的第一個工具:?
./node_modules/.bin/eslint --fix --ignore-path .gitignore .
? - 如果你有 ESLint 預測試腳本,你還可以執(zhí)行以下操作:?
npm run pretest -- --fix
? - 有一些類的問題,ESLint不會解決,然而,在這種情況下,你可以用做一次性清理prettier。prettier 最常用作 ESLint 和 auto-formats 源在提交之前的替代品。它在引導 ESLint 時也非常有用。像這樣運行它:
- 這是放寬?
max-len
?規(guī)則以允許最多 120 個字符寬的連續(xù)行的示例: - 一旦您的代碼干凈利落(使用?
npm run pretest
? 檢查),提交結(jié)果:
npm i prettier ./node_modules/.bin/prettier --single-quote --trailing-comma es5 --print-width 80 --write --no-bracket-spacing **/*.js
運行?eslint --fixand
? 后prettier,你應該只有很少的剩余警告需要手動清理。雖然 prettier 不像 ESLint 那樣常用,但如果需要,它可以用作 ESLint 的補充(prettier 用于自動格式化,ESLint 用于格式強制和錯誤檢查)。如果由于某種原因您現(xiàn)在沒有時間修復這些問題,請禁用 ESLint 規(guī)則。自動強制執(zhí)行某些樣式子集比完全不強制要好得多。您可以為特定項目覆蓋一些 StrongLoop 樣式,然后有時間回來清理代碼。
{
"extends": "strongloop",
"rules":
{
"max-len": [2, 120, 8]
}
}
你可能會發(fā)現(xiàn)你的代碼使用了一致的風格,但不是 StrongLoop 的風格。如果接近,你可以自定義StrongLoop樣式并發(fā)布為你自己的。如果你的風格完全不同,那么編寫和發(fā)布你自己的可重用配置可能是有意義的。
git commit -a -m 'Project lints clean
自動lint
有兩個級別的自動化:項目范圍的策略和您自己的個人設(shè)置。
就項目范圍的策略而言,因為 ESLint 被配置為與您的測試一起運行,所以沒有什么可做的。除非你沒有為你的項目自動運行測試,在這種情況下是時候開始了!
就我自己的個人設(shè)置而言,我更喜歡在我的每個提交上運行 ESLint,因此我引入的任何問題都在我的機器上被 CI 捕獲之前捕獲。我用一個? git pre-commithook
?來做這個。
要進行設(shè)置,請使用示例鉤子作為基礎(chǔ):
?cp .git/hooks/pre-commit.sample .git/hooks/pre-commi
?t
文件的最后幾行將如下所示:
# If there are whitespace errors, print the offending file names and fail.
exec git diff-index --check --cached $against --
將其更改為如下所示:
set -e
npm run pretest
# If there are whitespace errors, print the offending file names and fail.
exec git diff-index --check --cached $against --
就是這樣,你現(xiàn)在是 eslint 的另一個用戶。