stylelint 搭配 stylelint-order,更随心所欲的编码 CSS

浏览: 38 发布日期: 2017-12-18 分类: css3

原文链接: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 规则

简单步骤

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 代码「部分规则还是需要抛出错误,开发者手动修复」

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

写在最后

虽然有各种各样的工具能「辅佐」开发者工作,注意,是「辅佐」不是「帮助」。
因为开发者自己需要明确「为什么」要这样校验,我们不能被工具「牵着鼻子走」,是我们「命令」工具这样校验。
嗯,这点很重要。
不然别人问这样做的好处,千万不要「一脸茫然」。


·感谢阅读·

返回顶部