建站
咨詢
售后
建站咨詢
新聞中心
前言：記得我剛開始參與到公司項(xiàng)目的開發(fā)時(shí)，由于代碼結(jié)構(gòu)太亂被同事集體 diss，而后被強(qiáng)烈要求打開 eslint 來開發(fā)，無奈之下陷入 eslint 的魔爪。但是當(dāng)我打開 eslint 的時(shí)候，我真的是去他喵的，代碼哪哪都給我爆紅，然后我就偷偷把 eslint 關(guān)掉了（機(jī)智如我 <(￣︶￣)>）。但是，果不其然，沒過多久我就又被抓住了。在經(jīng)歷了幾次貓抓老鼠的游戲之后，我終于習(xí)慣并且喜歡上 eslint 了。
創(chuàng)新互聯(lián)長期為近1000家客戶提供的網(wǎng)站建設(shè)服務(wù)，團(tuán)隊(duì)從業(yè)經(jīng)驗(yàn)10年，關(guān)注不同地域、不同群體，并針對(duì)不同對(duì)象提供差異化的產(chǎn)品和服務(wù)；打造開放共贏平臺(tái)，與合作伙伴共同營造健康的互聯(lián)網(wǎng)生態(tài)環(huán)境。為萬源企業(yè)提供專業(yè)的成都網(wǎng)站制作、做網(wǎng)站、外貿(mào)營銷網(wǎng)站建設(shè)，萬源網(wǎng)站改版等技術(shù)服務(wù)。擁有十余年豐富建站經(jīng)驗(yàn)和眾多成功案例,為您定制開發(fā)。
在這篇文章中，我不會(huì)花太多的筆墨去介紹 Eslint 的使用，因?yàn)槟鞘枪俜轿臋n該做的事情。我所希望做到的是，在閣下看完這篇文章之后，能夠超脫于 Eslint 本身，去看到它所實(shí)現(xiàn)的需求本身，即實(shí)現(xiàn) js/ts 的代碼檢查。而后，我會(huì)以實(shí)現(xiàn)代碼檢查這個(gè)需求為出發(fā)點(diǎn)，引出代碼 eslint 的四種代碼檢查姿勢(shì)。
對(duì)于代碼檢查需求及其實(shí)現(xiàn)方案，我從個(gè)人認(rèn)識(shí)出發(fā)，用腦圖做了以下整理：
接下來的行文，我都會(huì)圍繞這副腦圖展開，如果您有興趣繼續(xù)往下看下去，我希望您能在這幅圖上停留多一些時(shí)間。
好的，按照上述腦圖中的邏輯，接下來我會(huì)分成以下幾個(gè)部分來展開探討本文。
- 理解代碼檢查
- 為項(xiàng)目接入 Eslint 實(shí)現(xiàn)代碼檢查
- 基于 Eslint 及其規(guī)則實(shí)現(xiàn) <編碼后檢查>
- 基于 Eslint 及其規(guī)則實(shí)現(xiàn) <編碼時(shí)檢查>
- 基于 Eslint 及其規(guī)則實(shí)現(xiàn) <構(gòu)建前檢查>
- 基于 Eslint 及其規(guī)則實(shí)現(xiàn)
好的，理清了行文思路之后，下面我們進(jìn)入第一部分，理解代碼檢查。
一：理解代碼檢查
代碼檢查，顧名思義就是檢查代碼，發(fā)生于開發(fā)階段，可有效幫助開發(fā)者減少 JavaScript 粗心代碼，如語法錯(cuò)誤、變量未定義、變量未使用等等問題。除此之外，代碼檢查還可以約束統(tǒng)一開發(fā)人員的代碼風(fēng)格，利于團(tuán)隊(duì)協(xié)作。
經(jīng)過上面這段話，我們就已經(jīng)達(dá)成了對(duì)代碼檢查的概念理解。下面我們?cè)購娜齻€(gè)方面來展開分析，加深對(duì)代碼檢查的實(shí)踐理解。這三個(gè)方面分別為以下三點(diǎn)：
- 代碼檢查的功能
- 代碼檢查的類型
- 代碼檢查的工具
好的，下面我們就先進(jìn)入代碼檢查功能的探討。
1. 代碼檢查的功能
我認(rèn)為，代碼檢查這個(gè)切面大概可以幫助我們做以下三件事情：
- 語言語法檢查：比如檢查出字符串引號(hào)或者函數(shù)調(diào)用括號(hào)沒有匹配等問題。
- 編碼錯(cuò)誤檢查：比如檢查出開發(fā)者在使用一個(gè)不存在的變量或者變量定義了卻沒有使用等問題。
- 代碼風(fēng)格檢查：比如檢查出開發(fā)者沒有使用分號(hào)（與所選風(fēng)格有關(guān)）等問題。
文外總結(jié)：切面所在層次，決定了該切面的職能上線。
理解了代碼檢查這個(gè)切面所可以實(shí)現(xiàn)的功能之后，下面我們就探討一下代碼檢查的類型。
2. 代碼檢查的方式
以代碼檢查發(fā)生的不同時(shí)間和場(chǎng)景來劃分，我把代碼檢查的方式分類成以下四種：
- 編碼時(shí)檢查：編寫代碼時(shí)檢查，通常表現(xiàn)為由 IDE 自動(dòng)實(shí)時(shí)檢查并進(jìn)行代碼提示。
- 編碼后檢查：編寫代碼后檢查，通常表現(xiàn)為手動(dòng)調(diào)用檢查腳本 / 工具進(jìn)行代碼的檢查或者代碼保存后由 IDE 自動(dòng)檢查當(dāng)前文件。
- 構(gòu)建前檢查：構(gòu)建執(zhí)行前檢查，通常表現(xiàn)為將代碼檢查作為構(gòu)建任務(wù)的一個(gè)前置切面，構(gòu)建時(shí)自動(dòng)觸發(fā)代碼檢查。
- 提交前檢查：git commit 前檢查，通常表現(xiàn)為將代碼檢查作為 git commit 的一個(gè) hooks 任務(wù)，代碼提交前自動(dòng)觸發(fā)代碼檢查。
如此無私分享，不值得你的點(diǎn)贊和關(guān)注鼓勵(lì)一下嗎？
理解代碼檢查的方式很重要，這直接反映了你對(duì)代碼檢查這個(gè)概念本身的掌握程度。廢話不多說，下面我們進(jìn)入代碼檢查工具的探討。
3. 代碼檢查工具
代碼檢查的實(shí)現(xiàn)通常不會(huì)僅僅是字符串分析處理，這其中會(huì)大量涉及到語法分析。既然涉及到語法，那么就需要對(duì)不同的代碼使用不同的代碼檢查工具，通常來說，我們會(huì)使用 Eslint 工具來實(shí)現(xiàn)對(duì) JavaScript 和 Typescript 代碼的檢查，使用 stylelint 工具對(duì)樣式代碼進(jìn)行代碼檢查。對(duì)于 stylelint，本文不多做敘述，接下來我們把舞臺(tái)交給 Eslint，一起探討一下如何使用 Eslint 實(shí)現(xiàn) JavaScript 代碼和 typescript 代碼的檢查。
好的，在按順序探討編碼后檢查、編碼時(shí)檢查、構(gòu)建前檢查、git 提交前檢查這四種代碼檢查方式之前，我們先為項(xiàng)目接入 Eslint，并配置各種代碼檢查方式都需要的檢查規(guī)則。
二：為項(xiàng)目接入 Eslint 實(shí)現(xiàn)代碼檢查
有不少朋友可能并不了解 Eslint，下面我們先對(duì)它做個(gè)簡單介紹。
Eslint 是一款插件（檢查規(guī)則）化的 JavaScript 代碼檢查工具。概念言簡意賅，需要注意的是，概念中說到 eslint 是一個(gè)插件化的檢查工具，其意思是指 eslint 的設(shè)計(jì)是把檢查工具和檢查規(guī)則之間解耦了。也就是說，在安裝好 eslint 的開發(fā)依賴之后，我們還可以并且需要選擇安裝一個(gè)我們中意的檢查規(guī)則。
好的，理論就說到這，接下來我們就從實(shí)踐中得到真知，實(shí)踐步驟如下：
step1：安裝檢查工具 eslint
- yarn add eslint --dev
step2：安裝并配置檢查規(guī)則
在探討配置安裝檢查規(guī)則之前，我們有必要先明確一下我們的檢查目標(biāo)是什么。我認(rèn)為，檢查目標(biāo)自然是構(gòu)建前的代碼，并且是自己 / 自己團(tuán)隊(duì)編寫的代碼（非第三方模塊）。畢竟檢查的最終目標(biāo)是為修復(fù)服務(wù)的，我們只負(fù)責(zé)修復(fù)自己 / 自己團(tuán)隊(duì)編寫的代碼，構(gòu)建后代碼以及第三方代碼即使檢查不通過我們也不會(huì)也不應(yīng)該由我們?nèi)バ迯?fù)。
檢查規(guī)則在項(xiàng)目中通常有兩種表現(xiàn)形式，即：
- 配置文件中配置的規(guī)則：主要形式，通過繼承和擴(kuò)展的方式聲明了大量規(guī)則
- 項(xiàng)目代碼中的魔法注釋：次要形式，通常是用于作為配置文件中規(guī)則的特例
生成 eslint 配置文件：
對(duì)于配置文件，我們通常會(huì)使用 eslint --init 命令來生成這個(gè)配置文件，下表列舉了一些調(diào)用這個(gè)命令之后經(jīng)常出現(xiàn)的配置問題（不一定會(huì)是依次下面幾個(gè)問題）。
注意：我覺得回答這些問題還是要慎重一些，因?yàn)閱栴}答案會(huì)影響配置，配置會(huì)影響檢查規(guī)則，檢查規(guī)則會(huì)影響檢查結(jié)果。當(dāng)然，回答這些問題的目的也就是生成想要配置文件，如果問題回答錯(cuò)了或者后續(xù)對(duì)規(guī)則有改動(dòng)也可以直接修改 eslint 配置文件。
| 序號(hào) | 作用 | 問題 |
|---|---|---|
| 1 | 選擇使用 eslint 的用途，常選 3 | How would you like to use ESLint? (Use arrow keys) To check syntax only To check syntax and find problems To check syntax, find problems, and enforce code style |
| 2 | 選擇項(xiàng)目使用的模塊化規(guī)范 | What type of modules does your project use? (Use arrow keys) JavaScript modules (import/export) only CommonJS (require/exports) None of these |
| 3 | 選擇項(xiàng)目使用的框架 | Which framework does your project use? (Use arrow keys) React Vue.js None of these |
| 4 | 是否使用 Typescript | Does your project use TypeScript? (y/N) |
| 5 | 選擇代碼的運(yùn)行環(huán)境（多選） | Where does your code run? (Press ( ) Browser ( ) Node |
| 6 | 選擇如何為你的項(xiàng)目定義風(fēng)格，常選 1 | How would you like to define a style for your project? (Use arrow keys) Use a popular style guide Answer questions about your style Inspect your JavaScript file(s) |
| 7 | 選擇使用具體的流行代碼風(fēng)格 | Which style guide do you want to follow? (Use arrow keys) Airbnb (https://github.com/airbnb/javascript) Standard (https://github.com/standard/standard) (https://github.com/google/eslint-config-google) |
| 8 | 選擇配置文件格式，常選 1（更靈活） | What format do you want your config file to be in? (Use arrow keys) JavaScript YAML JSON |
代碼中的魔法注釋寫法：
除了配置文件中配置規(guī)則，eslint 還有一個(gè)代碼中通過魔法注釋打規(guī)則補(bǔ)丁的辦法，如下示例：
- // 屏蔽整行的代碼檢查
- const str1 = "${name} is a coder" // eslint-disable-line
- // 屏蔽某一個(gè)規(guī)則：如此行的no-template-curly-in-string規(guī)則
- const str1 = "${name} is a coder" // eslint-disable-line no-template-curly-in-string
溫馨提示：規(guī)則名稱可以從檢查結(jié)果提示或輸出信息中得到
三：基于 Eslint 及其規(guī)則實(shí)現(xiàn) <編碼后檢查>
對(duì)于一個(gè)工作流程的解釋，我還是更傾向于直接演示一個(gè)簡單的 demo。在這個(gè)行文思路下，下面我們就分別演示一個(gè) Eslint 檢查 JS 代碼的示例以及一個(gè) Eslint 檢查 TS 代碼的示例。根據(jù)代碼檢查的邏輯，demo 演示和講解時(shí)我會(huì)遵循以下思路，即：
- 目標(biāo)問題代碼
- 代碼檢查規(guī)則配置
- 代碼檢查操作和結(jié)果
- 修復(fù)代碼操作
好的，下面我們就進(jìn)入 Eslint 對(duì) JS 代碼編碼后檢查示例的探討。
1.Eslint 編碼后檢查 JS 代碼示例
1): 目標(biāo)問題代碼
- const noUsedVar = 1;
- function fn() {
- console.log('hello')
- cnsole.log('eslint');
- }
- fn(
- fn2();
以上短短幾行代碼就可以表示出 eslit 代碼檢查的三個(gè)部分，它們分別是：
- 語法錯(cuò)誤
- 編碼錯(cuò)誤：未定義、未使用
- 編碼風(fēng)格：沒有分號(hào)
2): 代碼檢查規(guī)則配置
通過 eslint --init，根據(jù)項(xiàng)目特征來回答問題之后得到的 eslint 配置文件如下：
- module.exports = {
- env: {
- browser: true,
- es6: true,
- },
- extends: [
- 'airbnb-base',
- ],
- globals: {
- Atomics: 'readonly',
- SharedArrayBuffer: 'readonly',
- },
- parserOptions: {
- ecmaVersion: 2018,
- },
- rules: {
- },
- };
3): 代碼檢查操作和結(jié)果
第一輪檢查結(jié)果先是報(bào)了語法錯(cuò)誤，在修復(fù)語法錯(cuò)誤之后，第二輪檢查報(bào)錯(cuò)了很多編碼以及風(fēng)格上的錯(cuò)誤。將兩次檢查結(jié)果關(guān)聯(lián)到問題代碼可以得到如下分析：
- const noUsedVar = 1; // find program：'noUsedVar' is assigned a value but never used
- function fn() {
- console.log('hello') // enforce code style：Missing semicolon（分號(hào)）
- cnsole.log('eslint'); // find program：'cnsole' is not defined
- }
- fn( // syntax error
- fn2(); // find program：'fn2' is not defined
4): 修復(fù)代碼
根據(jù)上述檢查結(jié)果進(jìn)行修復(fù)。對(duì)于代碼風(fēng)格上的不一致導(dǎo)致的錯(cuò)誤，通過參數(shù) --fix 即可以自動(dòng)修復(fù)大部分的問題。而對(duì)于語法以及編碼上的錯(cuò)誤則大部分只能是開發(fā)者自己手動(dòng)修復(fù)。經(jīng)過手動(dòng)修復(fù)以及自動(dòng)修復(fù)之后，問題代碼可能變?yōu)槿缦履樱?/p>
- import { fn2 } from './test2';
- function fn() {
- console.log('hello');
- console.log('eslint');
- }
- fn();
- fn2();
2.Eslint 編碼后檢查 TS 代碼示例
1): 目標(biāo)問題代碼
- function foo(ms: string): void{
- console.log(msg);
- }
- foo("hello typescript~")
2): 代碼檢查規(guī)則配置
項(xiàng)目安裝 typescript 依賴后（不先安裝 typescript 依賴就執(zhí)行 eslint --init 會(huì)報(bào)錯(cuò)），通過 eslint --init 命令，根據(jù)項(xiàng)目特征來回答問題（typesrcipt yes）之后得到的 eslint 配置文件如下：
- module.exports = {
- "env": {
- "browser": true,
- "es6": true
- },
- "extends": [
- "airbnb-base"
- ],
- "globals": {
- "Atomics": "readonly",
- "SharedArrayBuffer": "readonly"
- },
- "parser": "@typescript-eslint/parser",
- "parserOptions": {
- "ecmaVersion": 2018
- },
- "plugins": [
- "@typescript-eslint"
- ],
- "rules": {
- }
- };
相對(duì)于 JavaScript 的代碼檢查，對(duì)于 typescript 的檢查需要額外的一個(gè)語法解析器（即上述配置中的 parser 配置項(xiàng)內(nèi)容）。
3): 代碼檢查操作和結(jié)果
eslint 以 --fix 參數(shù)檢查之后，主要報(bào)了兩個(gè)編碼錯(cuò)誤，映射到文件中分析如下：
- function foo(ms: string): void { // 'ms' is defined but never used
- console.log(msg); // 'msg' is not defined
- }
- foo('hello typescript~');
4): 修復(fù)代碼
在本示例中，在 fix 自動(dòng)修復(fù)代碼風(fēng)格之后，手動(dòng)把 foo 函數(shù)的形參改為 msg 即可。
- function foo(msg: string): void {
- console.log(msg);
- }
- foo('hello typescript~');
四：基于 Eslint 及其規(guī)則實(shí)現(xiàn) <編碼時(shí)檢查>
說到編碼時(shí)檢查就不得不提到代碼提示，也不得不聯(lián)系到我們所具體選擇使用的 IDE。除此之外，為了保證多種方式下代碼檢查規(guī)則的統(tǒng)一配置，我們還需要做到的關(guān)鍵一點(diǎn)是 IDE 能夠讀取我們?cè)陧?xiàng)目中配置的 eslint 規(guī)則文件去實(shí)時(shí)檢查代碼。
由于個(gè)人主要使用 VScode 開發(fā)，所以下面做的 demo 和探討都默認(rèn)在 vscode 環(huán)境下。官方相關(guān)資料：Eslint 的官方整合工具列表中的 [1. 安裝 eslint、配置 eslint 規(guī)則](https://marketplace.visualstudio.com/items?item>Visual Studio Code: ESLint Extension 文檔。
說實(shí)話，這個(gè)東西我也是現(xiàn)學(xué)現(xiàn)賣，畢竟前端要學(xué)的東西實(shí)在太多了，而且這篇文章的初衷也不是對(duì)某一技術(shù)點(diǎn)的面面俱到，而是幫助你建立系統(tǒng)化認(rèn)識(shí)以及引導(dǎo)。
由于我們需要做到在 IDE 實(shí)時(shí)代碼檢查時(shí)，能夠讀取讀取項(xiàng)目下的 eslint 規(guī)則。所以以下兩個(gè)步驟必不可少：
- 安裝 eslint、配置 eslint 規(guī)則
- IDE 實(shí)時(shí)代碼檢查功能相關(guān)安裝配置
根據(jù)以上實(shí)現(xiàn)步驟思路，下面我們就做一個(gè)vscode環(huán)境下，基于Eslint及其規(guī)則實(shí)現(xiàn)編碼時(shí)檢查的demo。
1.安裝eslint、配置eslint規(guī)則
- yarn add eslint --dev # 安裝
- eslint --init # 初始化配置
eslint的規(guī)則配置方式上面已經(jīng)討論過，這里就不再展開贅述了。
2.IDE 實(shí)時(shí)代碼檢查功能相關(guān)安裝配置
在 eslint 工具以及檢查規(guī)則準(zhǔn)備好之后（該規(guī)則就是 IDE 代碼檢查的規(guī)則），剩下的具體的檢查行為觸發(fā)以及代碼提示工作就要交給 IDE 來實(shí)現(xiàn)了。對(duì)于 vscode，這里我們的實(shí)現(xiàn)思路是安裝 eslint 這個(gè)擴(kuò)展插件（個(gè)人使用的版本 2.1.14，下面的配置 1.x 很可能不適用），而后注意打開 vscode 的 eslint 代碼檢查功能（vscode 下的 eslint 開關(guān)為右下角的 eslint 文字標(biāo)識(shí)）即可實(shí)現(xiàn) vscode 環(huán)境下的 eslint 實(shí)時(shí)代碼檢查。
配置 IDE 的實(shí)時(shí)檢查功能
如果需要對(duì) IDE 的實(shí)時(shí)檢查功能做一些配置，則可以通過 打開 vscode 的 setting -> 找到 eslint -> 打開 setting.json 這幾個(gè)步驟來找到相關(guān)的配置文件，以下是配置 vscode 代碼檢查功能示例:
- //配置eslint
- "editor.codeActionsOnSave": { // 保存時(shí)自動(dòng)fix
- "source.fixAll.eslint": true
- },
- "eslint.quiet": true, // warning時(shí)不報(bào)紅色下劃線，可用于處理no-console規(guī)則爆的warning
實(shí)時(shí)代碼檢查報(bào)錯(cuò)后的修復(fù)
在 IDE 自動(dòng)檢查的過程中，報(bào)錯(cuò)提示如果報(bào)的是代碼觸犯了規(guī)則的提示，那么就可以修改項(xiàng)目下的檢查規(guī)則文件（.eslintrc.js）。比如個(gè)人在 demo 實(shí)踐中就遇到了 ESLintExpected linebreaks to be 'LF' but found 'CRLF'這個(gè)規(guī)則錯(cuò)誤，并且它的情況還有些特殊，它在 IDE 實(shí)時(shí)檢查會(huì)報(bào)，但是手動(dòng)調(diào)用 eslint 命令時(shí)不報(bào)，具體原因在此不多做分析，個(gè)人是直接在規(guī)則文件（.eslintrc.js）加入以下規(guī)則得以解決的：
- rules: {
- 'linebreak-style': [0, 'error', 'windows'],
- },
五：基于 Eslint 及其規(guī)則實(shí)現(xiàn) <構(gòu)建前檢查>
下面我們直接進(jìn)入現(xiàn)如今較為常用的 gulp 以及 webpack 構(gòu)建工具如何實(shí)現(xiàn)構(gòu)建前檢查的探討。
1.gulp 構(gòu)建前檢查
通過 gulp 實(shí)現(xiàn)這個(gè)代碼檢查切面的思路如下：
- 安裝 eslint 并初始化 eslint 配置文件
- 下載安裝 gulp-eslint 插件
- 編寫 js 文件處理的代碼檢查切面
1): 初始化 eslint 配置文件
- yarn add eslint --dev
- eslint --init
2): 下載安裝 gulp-eslint 插件
- yarn add gulp-eslint --dev
3): 編寫 js 文件處理的代碼檢查切面
示例如下：
- // ... 其它代碼
- const eslint = require('gulp-eslint');
- const script = (0 => {
- return src(['scripts/*.js'])
- .pipe(eslint()) // 代碼檢查
- .pipe(eslint.format()) // 將lint結(jié)果輸出到控制臺(tái)。
- .pipe(eslint.failAfterError()) // lint錯(cuò)誤，進(jìn)程退出，結(jié)束構(gòu)建。
- .pipe(babel({ presets: ['@babel/preset-env']}))
- .pipe(dest('temp'))
- .pipe(bs.reload( { stream: true } ))
- }
- // ... 其它代碼
2.webpack 構(gòu)建前檢查
通過 webpack 來實(shí)現(xiàn)這個(gè)代碼檢查切面的思路如下：
- 安裝 eslint 并初始化 eslint 配置文件
- 安裝 eslint-loader
- 編寫 webpack 配置文件，為 js 文件加上這個(gè) eslint-loader
(1): 安裝 eslint 并初始化 eslint 配置文件
- yarn add eslint --dev
- eslint --init
(2): 安裝 eslint-loader
- yarn add eslint-loader --dev
(3): 編寫 webpack 配置文件，為 js 文件加上這個(gè) eslint-loader
- rules: [
- {
- test: /.js$/,
- exclude: /node_modules/,
- use: [
- 'babel-loader',
- 'eslint-loader' // 更后的先執(zhí)行
- ]
- }
- ]
六：基于 Eslint 及其規(guī)則實(shí)現(xiàn)
這一個(gè)部分的講解，我接下來會(huì)從以下四個(gè)方面循序漸進(jìn)的探討 Eslint 如何實(shí)現(xiàn) git 的提交前檢查：
- 1.git 提交前檢查原理：Git Hooks
- 使用 husky 實(shí)現(xiàn)：編寫 node 代碼替代 shell 代碼
- 實(shí)現(xiàn) hook 任務(wù)流：通過 lint-staged 來配合 husky 來實(shí)現(xiàn)
- 實(shí)現(xiàn) git 提交前檢查：先執(zhí)行 eslint 任務(wù)而后執(zhí)行 git add 任務(wù)
下面我們進(jìn)入第一點(diǎn)，git 提交前檢查原理：Git Hooks 的探討。
1.git 提交前檢查原理：Git Hooks
Eslint 實(shí)現(xiàn) git 的提交前檢查是通過 Git Hooks 實(shí)現(xiàn)的，Git Hook 也稱之為 git 鉤子，每個(gè)鉤子都對(duì)應(yīng)一個(gè)任務(wù)，通過 shell 腳本可以編寫鉤子任務(wù)觸發(fā)時(shí)要具體執(zhí)行的操作。
本文關(guān)注實(shí)現(xiàn) git 提交前的代碼檢查，所以我們關(guān)注 git commit 這個(gè)鉤子，使用步驟如下：
- 編寫 hook 任務(wù)：項(xiàng)目的. git/hooks 文件夾下新建一個(gè) pre-commit 文件
- #!/bin/sh
- echo "before commit"
- 觸發(fā)鉤子：項(xiàng)目下執(zhí)行 git commit 命令
git commit 命令執(zhí)行后，可以發(fā)現(xiàn) commit 操作不管是否成功，都可以看到輸出的 before commit 信息。
上述方式可用但還在實(shí)際生產(chǎn)中使用還是不太合適，畢竟對(duì)于前端開發(fā)者來說，使用 shell 腳本編寫 git hook 的方式還是比較難接收，下面我們介紹 husky 這個(gè)庫的使用，幫助我們達(dá)成以 js 代碼的方式來編寫 hook 任務(wù)的目的。
2. 使用 husky 實(shí)現(xiàn)：編寫 node 代碼替代 shell 代碼
實(shí)現(xiàn)步驟如下：
- (1): 安裝 husky
- (2): 配置 husky 的 hook 任務(wù)：如下 package.json 任務(wù)
- (3): 觸發(fā)鉤子：git add -> git commit
1): 安裝 husky
- yarn add husky --dev
在安裝好這個(gè)模塊后，就可以在. git/hooks 文件夾下看到如下這些新添加的文件。
2): 配置 husky 的 hook 任務(wù)：如下 package.json 任務(wù)
- "scripts": {
- "test1": "echo before commit",
- "test2": "node test2.js"
- },
- "husky": {
- "hooks": {
- "pre-commit": "yarn test2"
- }
- },
3): 觸發(fā)鉤子：git add -> git commit
git commit 命令執(zhí)行后，就可以觸發(fā)我們通過 husky 實(shí)現(xiàn)的由 js 代碼編寫的 hook 任務(wù)。
下面我們?cè)鰪?qiáng)一下，通過 lint-staged 這個(gè)庫，讓 hook 不但支持單任務(wù)還支持任務(wù)流的觸發(fā)。
3. 實(shí)現(xiàn) hook 任務(wù)流：通過 lint-staged 來配合 husky 來實(shí)現(xiàn)
實(shí)現(xiàn)步驟如下：
- (1): 安裝 husky 和 lint-staged 模塊
- (2): 配置 husky 的 hook 任務(wù)流：如下 package.json 任務(wù)
- (3): 觸發(fā)任務(wù)流：git add -> git commit
1): 安裝 husky 和 lint-staged 模塊
- yarn add husky --dev
- yarn add lint-staged --dev
2): 配置 husky 的 hook 任務(wù)流：如下 package.json 任務(wù)
- "scripts": {
- "precommit": "lint-staged"
- },
- "husky": {
- "hooks": {
- "pre-commit": "yarn precommit"
- }
- },
- "lint-staged": {
- "*.js":[
- "echo task1",
- "echo task2",
- "echo task3"
- ]
- }
3): 觸發(fā)任務(wù)流：git add -> git commit
實(shí)踐發(fā)現(xiàn)，與單獨(dú)的 husky 模塊實(shí)現(xiàn)單任務(wù)相比而言，使用 lint-staged 之后，git commit 命令只有成功執(zhí)行（有 add 資源并且有提交信息）才會(huì)觸發(fā) lint stage 中的操作，且這些操作只會(huì)對(duì) js 文件有效。
好的，經(jīng)過以上鋪墊，下面我們就可以進(jìn)入我們所要實(shí)現(xiàn)的最終需求，即實(shí)現(xiàn) git 提交前檢查的探討了。
4. 實(shí)現(xiàn) git 提交前檢查：先執(zhí)行 eslint 任務(wù)而后執(zhí)行 git add 任務(wù)
實(shí)現(xiàn)步驟如下：
- (1): 安裝 husky 和 lint-staged 模塊
- (2): 配置 husky 的 hook 任務(wù)流：如下 package.json 任務(wù)
- (3): 觸發(fā)任務(wù)流：git add -> git commit
1): 安裝 husky 和 lint-staged 模塊
- yarn add husky --dev
- yarn add lint-staged --dev
2): 配置 husky 的 hook 任務(wù)流：如下 package.json 任務(wù)
- "scripts": {
- "precommit": "lint-staged"
- },
- "husky": {
- "hooks": {
- "pre-commit": "yarn precommit"
- }
- },
- "lint-staged": {
- "*.js":[
- "eslint --fix",
- "git add"
- ]
- }
3): 觸發(fā)任務(wù)流：git add -> git commit
經(jīng)過這些開發(fā)包的下載以及配置，在我們執(zhí)行 git commit 之后，就會(huì)觸發(fā) husky 配置的 pre-commit 的 hook 任務(wù)，而這個(gè) hook 任務(wù)又把任務(wù)交給了 lint-staged 處理，進(jìn)而通過 lint-staged 實(shí)現(xiàn)對(duì) js 文件的代碼檢查以及自動(dòng)風(fēng)格修復(fù)后（還是錯(cuò)誤則會(huì)中斷提交）重新 add，而后再執(zhí)行 commit 任務(wù)，保證了代碼在提交前一定經(jīng)過了代碼檢查。
分享題目：內(nèi)容非常詳細(xì)！領(lǐng)略Eslint代碼檢查的四種姿勢(shì)
本文URL：http://www.5511xx.com/article/dpcoeoj.html
