手摸手帶你實踐標準的前端開發規範

概述

掘金上發了"制定本身團隊的前端開發規範"帖子以後，有好多人給我說光寫規範可不行，要進行實踐，這篇文章就是告訴你們怎麼將咱們以前寫的規範進行實踐，光說不練假把式，咱們要在項目中強制執行這些規範。

主要使用 husky+lint-staged+eslint 對咱們的規範進行實踐，首先給你們介紹一下這幾個工具都是幹什麼用的。

• eslint：就很少作介紹了，你們應該都知道，咱們制定的規範須要用一些配置來實現，這個時候用 eslint 是最好不過的了。

• husky：能夠用於實各類 Git Hook。這裏主要用到 pre-commit 這個 hook，在執行 commit 以前，運行一些自定義操做。

• lint-staged：用於對 Git 暫存區中的文件執行代碼檢測。

知道了這幾個包的做用以後，咱們開始來給一個項目實現一套在提交代碼以前的 eslint 檢測。

ESlint

首先開始配置一下本身的 eslint，你們不要着急，接下來我會放一份純正的 vue 配置，複製粘貼過來就行，若是是純 JS、TS、React 的項目，能夠根據騰訊的 eslint-config-alloy 配置。

開始實踐吧：

• 進入你的項目中，我這裏新建一個項目開始配置

# 要遵循文件夾命名規範
mkdir eslint_test
cd eslint_test
# 一路回車就行
npm init
# 安裝 eslint 和 babel-eslint
npm i eslint babel-eslint -D
# 配置其餘的 eslint-config，須要根聽說明安裝其餘依賴
複製代碼

• 接着咱們在項目的根目錄下建立 eslint 的相關文件：

# eslint 要忽略的文件
touch .eslintignore
# eslint 的規則
touch .eslintrc.js
複製代碼

• 在 .eslintignore 文件中填寫 eslint 要過濾的文件

build/*.js
src/assets
public
dist
複製代碼

• 配置 .eslintrc.js

直接看一下我以前寫的制定本身團隊的前端開發規範之 eslint，，去 copy 一下我根據制定的 eslint 配置，粘貼到 .eslintrc.js 中便可。

• 接下來咱們要配置一下 package.json 裏面的執行腳本：

"scripts": {
  "lint": "eslint --ext .js --fix"
}
複製代碼

主要是檢測 js 代碼，而後經過 --fix 把 eslint 能解決的問題都在檢測的時候解決掉，好比格式，好比變量合併。

OK 了，eslint 的規範咱們已經制定完了，接下來就要在 git 提交代碼的時候對咱們所寫的代碼進行檢測了。

husky+lint-staged

先安裝一下咱們須要的 npm 包：

npm i lint-staged husky -D
複製代碼

接下來要在 package.json 裏面配置一下咱們的 git 鉤子：

{
  "name": "eslint_test",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "lint": "eslint --ext .js --fix"
  },
  "husky": {
    "hooks": {
      "pre-commit": "lint-staged"
    }
  },
  "lint-staged": {
    "src/**/*.{js,vue}": ["npm run lint", "git add"]
  },
  "author": "",
  "license": "ISC",
  "devDependencies": {
    "babel-eslint": "^10.0.2",
    "eslint": "^6.1.0",
    "husky": "^3.0.1",
    "lint-staged": "^9.2.1"
  }
}
複製代碼

husky 裏面定義了 git 的鉤子函數，咱們主要在 commit 以前進行檢查，因此用到了 pre-commit 這個鉤子。

lint-staged 在 pre-commit 的時候執行，定義了對 git 暫存區中的文件執行的任務，咱們這裏只對 js 文件作 eslint 的格式化校驗。

可是這裏有個小坑，你們必定要注意一下：

由於 pre-commit 這個鉤子是須要配合 git 去用的，它主要對文件夾 .git/hooks/pre-commit 文件作手腳，當咱們從 git 上拉下來項目時，若是以前沒對 hooks 下的文件作修改，那 hooks 下的文件都是以 sample 結尾的，這個時候鉤子函數是不起做用的，當咱們安裝了 husky 以後，husky 會自動對 hooks 下面的文件作修改，當你安裝完 husky 以後，再打開 .git/hooks 文件夾，你會發現全部的鉤子文件，都會存在一份帶有.sample 的，一份不帶.sample 的，不帶.sample 的文件就是 husky 建立的，這個纔會讓 git 鉤子起做用。因此咱們最好是先拉項目，而後再安裝 husky，不然可能會致使 husky 失效。若是你是新開發項目，開發完後才提交到 git，開發完以後，你能夠先關聯 git 倉庫，而後從新安裝一下 husky 這個包就能夠了。

這一套配置下來就能夠把咱們以前制定的前端規範強制執行了，怎麼樣，你會將這一套用到本身的項目中嗎？目前我本身就在用，感受仍是很不錯的，能夠規避不少細節上的問題，若是你還沒用上這一套，那你就須要趕快去實踐一下了。

開發中代碼格式化

上面的主要是在提交代碼的時候進行格式化，這樣會保證咱們遠程 git 倉庫裏面的代碼都是統一的，其實本地開發的時候咱們可使用 prettier 進行格式化，也很是好用，支持不少編輯器，能夠自行搜索配置。

閱讀完後兩部曲

很是感謝各位花時間閱讀完，衷心但願各位小夥伴能夠花少許的時間幫忙作兩件事：

• 動動你的手指，幫忙點個贊吧，你的點贊是對我最大的動力。

• 但願各位關注一下個人公衆號，新的文章第一時間發到公衆號，公衆號主要發一些我的隨筆、讀書筆記、還有一些技術熱點和實時熱點，而且還有很是吸引人的我我的自費抽獎活動哦~