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」，详细使用规则，这里不赘述。 移步阅读

写在最后

虽然有各类各样的工具能「辅佐」开发者工做，注意，是「辅佐」不是「帮助」。
由于开发者本身须要明确「为何」要这样校验，咱们不能被工具「牵着鼻子走」，是咱们「命令」工具这样校验。
嗯，这点很重要。
否则别人问这样作的好处，千万不要「一脸茫然」。

---

·感谢阅读·