前言
团队合作时，当每个人的代码都拥有自定义的格式化方式时，在提交merge的时候往往要解决很多冲突，此时我们可以使用eslint+stylelint来对团队的代码进行约束。
正文
stylelint是一个强大的，现代的代码检查工具，可以帮助你在团队合作中强制执行样式约定。
1. 安装stylelint
yarn add -D stylelint
2. 配置文件
使用 stylelint检测器需要一个配置对象，你可以使用三种方式来创建这个对象。
package.json 中的stylelint 属性。
.stylelintrc.js文件
stylelint.config.js 文件输出的js对象
一旦发现它们中的任何一个，将不再继续进行查找，进行解析，将使用解析后的对象。 本次使用的是.stylelintrc.js 文件来进行配置。
3. 使用stylelint
安装官方文档的说法你可以按照以下方法运行stylelint检测样式代码。
--fix 用来自动修复，但不能修复所有的问题。
// package.json
"scripts":{
"lint:css":"stylelint src/**/*.css --fix"
}
踩坑点1：
由于我的项目里使用的样式语言是less。所以检测css是肯定不对的，所以这里我们需要做一点改动
// package.json
"scripts":{
"lint:css":"stylelint src/**/*.less --fix"
}
于是我们可以运行这串代码了
yarn lint:css postcss-less
大家可以看到，这里报了一些提醒，简单翻译为让我们用对应的语法去解析我们的样式。而这对应的语法解析器是需要我们去安装的。
yarn add -D postcss-less
于是再次对脚本进行修改。
// package.json
"scripts":{
"lint:css":"stylelint src/**/*.less --fix --custom-syntax postcss-less"
}
OK 到这里我们就可以正常的去跑lint命令对我们的样式代码进行格式化了。接下来我们来配置lint规则
4. 配置规则
我们首先需要安装三个npm包帮助我们完善规则
yarn add -D stylelint-config-standard stylelint-order stylelint-config-css-modules
stylelint-config-standard 是stylelint的推荐配置，stylelint-order是用来在格式化css文件时对代码的属性进行排序。
stylelint-config-css-modules 是css-module的方案来处理样式文件
我的配置文件长这样：
// .stylelintrc.js
module.exports = {
processors: [],
plugins: ['stylelint-order'],
extends: [
"stylelint-config-standard",
"stylelint-config-css-modules"
],
rules: {
"selector-class-pattern": [ // 命名规范 -
"^([a-z][a-z0-9]*)(-[a-z0-9]+)*$",
{
"message": "Expected class selector to be kebab-case"
}
],
"string-quotes":"single", // 单引号
"at-rule-empty-line-before": null,
"at-rule-no-unknown":null,
"at-rule-name-case": "lower",// 指定@规则名的大小写
"length-zero-no-unit": true, // 禁止零长度的单位（可自动修复）
"shorthand-property-no-redundant-values": true, // 简写属性
"number-leading-zero": "never", // 小数不带0
"declaration-block-no-duplicate-properties": true, // 禁止声明快重复属性
"no-descending-specificity": true, // 禁止在具有较高优先级的选择器后出现被其覆盖的较低优先级的选择器。
"selector-max-id": 0, // 限制一个选择器中 ID 选择器的数量
"max-nesting-depth": 3,
"indentation": [2, { // 指定缩进 warning 提醒
"severity": "warning"
}],
"order/properties-order": [ // 规则顺序
"position",
"top",
"right",
"bottom",
"left",
"z-index",
"display",
"float",
"width",
"height",
'max-width',
'max-height',
'min-width',
'min-height',
'padding',
'padding-top',
'padding-right',
'padding-bottom',
'padding-left',
'margin',
'margin-top',
'margin-right',
'margin-bottom',
'margin-left',
'margin-collapse',
'margin-top-collapse',
'margin-right-collapse',
'margin-bottom-collapse',
'margin-left-collapse',
'overflow',
'overflow-x',
'overflow-y',
'clip',
'clear',
'font',
'font-family',
'font-size',
'font-smoothing',
'osx-font-smoothing',
'font-style',
'font-weight',
"line-height",
'letter-spacing',
'word-spacing',
"color",
"text-align",
'text-decoration',
'text-indent',
'text-overflow',
'text-rendering',
'text-size-adjust',
'text-shadow',
'text-transform',
'word-break',
'word-wrap',
'white-space',
'vertical-align',
'list-style',
'list-style-type',
'list-style-position',
'list-style-image',
'pointer-events',
'cursor',
"background",
"background-color",
"border",
"border-radius",
'content',
'outline',
'outline-offset',
'opacity',
'filter',
'visibility',
'size',
'transform',
],
}
};
processors 属性由于此次并没有使用，所以不做介绍，有兴趣的同学可以查询官方文档。
plugins 是由社区创建的规则或规则集，支持方法论、工具集，非标准 的 CSS 特性，或非常特定的用例。
extends 继承一个已存在的配置文件。（在我的配置中，继承了css-module和官方推荐的配置）
rules 规则决定检测器要查找什么和要解决什么，所以，通过该选项你就可以开启相应规则，进行相应的检测。所有规则必须显式的进行配置，因为 没有默认值。
注意： null为禁用规则。可以在rules里面重写覆盖官方推荐的配置规则。
5. 忽略lint文件
此时我们已经可以正常的使用stylelint来格式化样式代码了。但是在项目中往往会存在一些不需要格式化的代码，比如我们会单独抽离一个overrides文件来重写antd的样式。显然这里是不需要格式化的，因为antd的选择器命名可能跟我们的规范不尽相同。所以我们需要在运行lint时忽略这个文件。
我们可以在.stylelintrc.js中配置ignoreFiles。
创建.stylelintignore文件。
我们可以通过 /* stylelint-disable */的方法，来对代码快进行忽略lint检测。
我采用的是第二种方法，配置如下：
// .stylelintignore *.js *.tsx *.ts *.json *.png *.eot *.ttf *.woff *.css src/styles/antd-overrides.less
6. 自动格式化
在进行完上文的配置之后，其实我们已经达到了规范的目的，但是如果每次都要跑一次lint无疑就会加重我们的编码负担。这里介绍两种方式在我们写样式代码时，对代码自动格式化的方法。
6.1 stylelint vs-code 插件
6.2 webpack plugin
为什么一个webpack插件可以帮助我们格式化样式代码呢，这是因为我们在热更新重新编译的时候，这个插件会帮我们检测代码。并根据.stylelintrc.js文件中配置的规则进行fix。 如果有lint错误可以选择让项目无法运行，避免将没有lint的样式上传到代码库。
于是我在使用这个插件的时候踩了好多坑，接下来我一一的说。
6.3 插件踩坑集锦
最开始时。按百度到的各路大神的写法，只需要这么配置就可以：
new StyleLintPlugin({
context: "src",
configFile: path.resolve(__dirname, './stylelintrc.js'),
files: '**/*.less',
failOnError: false,
quiet: true,
syntax: 'less'
})
结局不出意料，没有用。最恐怖的是他会给你一种假象，你本地运行的时候没有任务问题，让你误以为你的代码没有任何问题！其实，是这个插件没有作用到。
另外这么配置如果使用stylelint的vscode扩展时，还会有一大堆的让你心态爆炸的红波浪~~~~。
经过我的踩坑，终于完成了一个没有报错，没有假象，没有错误检查，没有忽略我的忽略配置的配置！
new StylelintPlugin({
configFile: path.resolve(__dirname, './.stylelintrc.js'),
extensions: ['less'],
files: 'src/**/*.less',
fix: true,
customSyntax: 'postcss-less',
lintDirtyModulesOnly: true,
threads: true,
exclude: ['node_modules', 'src/styles/antd-overrides.less'],
})
7. commit检测
这个就比较简单了，如果项目之前配置过eslint时的commit检测，这里只需要在脚本中加入检测样式就可以。配置如下
"lint-staged": {
"*.{ts,tsx}": [
"eslint --ext js,ts,tsx --fix",
"git add"
],
"*.less": [
"stylelint --fix --custom-syntax postcss-less",
"git add"
]
}
这里其实是不需要跑yarn lint:css的，因为如果这样在commit时会全量检测所有src下的样式，然而其实我们只需要检测修改的文件即可。
特别注意： 一定要加上 --custom-syntax postcss-less。
以上就是引入stylelint实战遇到问题经验总结分享的详细内容，更多关于引入stylelint实战问题分享的资料请关注脚本之家其它相关文章！