stylelint 搭配 stylelint-order，更爲所欲爲的編碼 CSS

原文連接：https://github.com/hangyangws...

爲何須要校驗 CSS 規則

對於編程語言進行「語法、書寫」校驗，能有效「歸併」不一樣開發者的「不一樣風格」，還能檢驗出一些語法錯誤。
好比 eslint 就能校驗 JS 代碼的「雞肋糟粕」。
對於 CSS 而言，不能算是嚴格意義的「編程語言」，可是在前端體系中卻不能小覷。
CSS 是以描述爲主的「樣式表」，若是「描述」得「混亂、沒有規則」，對於其餘開發者必定是一個「定時炸彈 ?『特別是有強迫症的人羣 ?』」
CSS 看似簡單，想要寫出漂亮的 CSS 仍是至關困難。CSS 爲何這麼難學？ - CSS 不是科學，而是藝術
因此校驗 CSS 規則的行動迫在眉睫，當即執行。

團隊協做在 CSS 書寫遇到的問題

請看如下場景：

小馮：你的 CSS 爲何不把 0.1 寫成 .1
小杰：CSS 解析器同樣能識別，很差較真好麼
小馮：好吧 ?，那爲何你的逗號後面沒有空格，我看着很難受啊
小杰：我看着不難受就好
小馮：???，那你能不能不要新建一個空的 CSS 文件啊！！！
…

不管是在社區、MR、平時交流中，類似的場景層出不窮，
這就是由於 CSS 規則不統一，致使的弊端「冰山一角」

CSS 哪些東西須要校驗

單純從代碼層面來講，CSS 校驗的東西其實蠻少的。
好比：屬性順序、小於 1 的小數要不要去掉 0、選擇器之間要不要加空格…
不過要細細的追究，校驗的東西仍是挺多的，好比 List of rules 列出了好多須要校驗的規則。

叮叮叮~~~，有個東西要說一下，CSS 語言自己對「規則」不敏感，幾乎是你想怎麼寫就怎麼寫，只要合乎「語法」。

怎麼校驗 CSS 規則

首先得有一個規則，其次開發者得遵照規則。
如何遵照：

1. 提交 「Merge Request」的時候，以「Code Review」的形式「人工校驗」。「好蠢啊，費時費力，效果差」

2. git commit 的時候「自動校驗」，校驗經過才能提交成功「(＾－＾)V 真好~~~」

經過 stylelint 校驗 CSS 規則

簡單步驟

• 安裝 stylelint、stylelint-order

npm i --save-dev stylelint stylelint-order

• 增長 stylelint 配置文件

項目根目錄添加文件 .stylelintrc 基本配置文件：

{
  "extends": "stylelint-config-standard",
  "plugins": [],
  "rules": {}
}

具體的配置文件內容，歡迎參考：點我呀
注：配置文件使用的 CSS 屬性排序規則來自 這裏

• 在 package.json 的 scripts 字段中添加相關命令

{
  "scripts": {
    "lint-css": "stylelint 'src/**/*.css' --fix",
  }
}

這樣就能夠手動執行 npm run lint-css 校驗 CSS 了。
'src/**/*.css' 以 blob 語法表示 CSS 文件的路徑。
--fix 表示讓 stylelint 儘量的自動修復 CSS 代碼「部分規則仍是須要拋出錯誤，開發者手動修復」

• 安裝 lint-staged、husky

npm i --save-dev lint-staged husky

• 增長 lint-staged 配置文件

項目根目錄添加文件 .lintstagedrc 基本配置文件：

{
  "src/**/*.css": [
    "stylelint --fix",
    "git add"
  ]
}

這樣就會在執行 git commit 以前會自動以 stylelint --fix 的方式校驗 src/**/*.css CSS 文件

stylelint 的更多使用方式

stylelint 不只僅能夠用於項目中，還能夠用於編輯器，好比「Sublime Text」，詳細使用規則，這裏不贅述。 移步閱讀

寫在最後

雖然有各類各樣的工具能「輔佐」開發者工做，注意，是「輔佐」不是「幫助」。
由於開發者本身須要明確「爲何」要這樣校驗，咱們不能被工具「牽着鼻子走」，是咱們「命令」工具這樣校驗。
嗯，這點很重要。
否則別人問這樣作的好處，千萬不要「一臉茫然」。

---

·感謝閱讀·