使用 stylelint 检查 CSS

您编写 CSS。可能有很多 CSS。您会犯错误。可能犯了很多错误。有人需要阻止您在 CSS 中犯错。

有时您的错误是真正的 bug。有时它只是粗心、不一致或不清楚的编码风格。其中一些错误起初可能看起来微不足道（取决于您的性格），但随着代码库的增长和老化，它们变得显而易见，因为越来越多的人插手代码库并进行丑陋的操作。您认为无法想象的事情。

您尝试控制自己。您的同事也会加入进来，在您偏离轨道时纠正您。但您和您的同事都是错误制造者，因此自然而然地、不可避免地会失败，至少在一定程度上是如此。后来您或其他一些可怜的家伙将承担那些溜进您 CSS 的错误的后果。

您和您的同事都不喜欢谈论您犯过的错误。这很尴尬。有时会让人沮丧和分裂。一些明确有助于代码库的约定，比如一致的格式化，当手动强制执行时，可能会显得过于挑剔和乏味。或者，它们会激发出您通常喜欢的人中固执己见的元素。

此外，您更希望立即得到纠正，而不是等待代码审查，这样才能让某人指出您重复了声明并应该清理空格。即时反馈将帮助您内化约定，并在您的 CSS 无法工作时少花些时间摸索。

您真正需要的是一个防止错误的机器

您需要一个可靠的防止错误的机器，它能够理解 CSS 并理解您：您的意图、偏好、理想和弱点。

这样的机器会有它的局限性。所有事物都是如此。但它的局限性将与您和您的同事的局限性不同。它可以防止的任何错误，它都会始终如一、孜孜不倦地阻止。同时，您和您的同事可以努力改进机器，扩展其能力并减少其局限性。如果它是开源的，来自世界各地的其他贡献者可以加入这项工作——其他容易出错的 CSS 作者同样致力于防止他们自己的错误。

CSS 作者需要代码检查器，就像其他所有人一样

我们称这些防止错误的程序为“代码检查器”。JavaScript 有几个很好的代码检查器。特别是 ESLint 已经创造了奇迹，向我们所有人展示了一个好的代码检查器可以有多么有用。但在 CSS 领域，我们还没有那么幸运。我们只有非常有限的选择：基于 Ruby 的、特定于预处理器的 scss-lint 和较旧的 CSS Lint。

但在 PostCSS 出现之前就是这样。除此之外，PostCSS 提供了构建更多互操作 CSS 工具的方法。它可以将任何类似 CSS* 的语法解析为抽象语法树 (AST)，供插件进行分析和操作。并且使用 自定义解析器，PostCSS 甚至可以处理非标准的、技术上“无效”的模式（如 // 注释）。

这些条件为一个强大的新样式表代码检查器提供了肥沃的土壤——由 PostCSS 提供支持，并从 scss-lint 和 ESLint 的最佳功能中汲取灵感。

我一直与几位合作者一起在这个项目上工作，现在我写这篇文章是为了向您介绍我们开发的工具：stylelint。

使用 stylelint 可以做的一些事情

以下是尝试总结 stylelint 的功能，其中包括超过一百条规则和彻底的可扩展性。

如果您在任何时候发现自己越来越不耐烦（“好吧，好吧：我相信 stylelint 创造了奇迹。没有必要再总结了。”）直接跳到下一节，在那里我会预测一些问题并提供一些提示。

＃1) 捕获错误

一些 stylelint 规则旨在捕获明显的错误，通常是您在匆忙、分心或昏昏欲睡时犯的打字错误或疏忽。例如，您可以禁止空块、无效的十六进制值、重复选择器、未知动画名称和错误的线性渐变语法。

其他规则尽力捕获更细微的错误。
有一条规则警告您，当您使用简写属性（如 margin）时，它会覆盖其一个长写对应项（如 margin-top），您可能无意中做到了这一点。还有一条规则警告您，当规则 A 在规则 B 之前出现，但实际上却覆盖了规则 B 时，会导致令人困惑的情况，因为规则 A 的选择器具有更高的特异性（例如，规则 A 是 .foo.bar {...}，规则 B 是 .foo {...}）。这是一个棘手的问题。

另一条规则使用 PostCSS 插件 doiuse 检查您的样式是否适用于您打算支持的浏览器。还有一条规则使用 css-colorguard 对颜色进行抱怨，因为这些颜色太相似，您可能本来打算它们相同。（注意到了吗？这是 stylelint 构建在 PostCSS 之上的主要优势之一：几乎不费吹灰之力，stylelint 可以引入使用其他分析性 PostCSS 插件的规则。）

＃2) 强制执行最佳实践

如果您在样式表中使用系统方法或为代码编写样式指南，您应该能够果断地禁止某些模式。stylelint 提供了实现这一目标的方法。

最重要的是，您需要控制选择器。毫不留情地。使用 stylelint，您可以禁止超过特定特异性的选择器，或对嵌套深度设置上限。您可以禁止选择器类别（例如，禁止 id 选择器）并提供正则表达式以对其余选择器进行命名约定。

您可以阻止使用 !important 或不适用于您支持的浏览器的浏览器黑客。如果您使用 Autoprefixer（您可能应该使用），您可以禁止在源样式表中使用供应商前缀。

如果您想认真对待——在配置中投入更多时间以确保绝对一致性——您可以强制执行规则中属性的顺序，并提供属性、值、函数和单位的黑名单和白名单。

＃3) 强制执行代码样式约定

stylelint 有一系列规则可以自动强制执行代码样式约定，这样您和您的团队成员就不必手动执行。我们努力使这些规则非常全面且非常灵活。

这些规则主要与空格有关，但也针对其他细节，例如引号、字母大小写、小数的领先零、使用关键字与拼写值等。

梦想是您和您的团队成员可以一次性建立一个格式化约定（例如，“让我们在声明的冒号后始终留一个空格！”），将其编入 stylelint 的配置中，然后不再讨论它。将执行权交给机器帝国。

＃4) 自定义和扩展所有内容

ESLint 的创建者 Nicholas Zakas（也是 CSS Lint 的创建者）已经写过，ESLint 成功的关键在于其可扩展性。stylelint 试图效仿 ESLint 的做法，并为 CSS 作者提供尽可能可扩展的代码检查器。

您可以编写并发布自己的规则作为插件。已经有 很多 可用的插件；我们很乐意看到大家想出的其他插件。

配置是可以扩展的，因此可以共享。与插件一样，我们从 ESLint 中学习了此功能的价值。看看 已经发布的内容，其中包括来自 WordPress 和 SUITCSS 的配置。

如果您不喜欢 stylelint 的内置报告器，您可以自己制作一个，甚至可以根据您的组织定制一个。您还可以自定义规则提供的警告消息。

使用 stylelint 的 API，您可以创建用于文本编辑器和任务运行器的插件，将 stylelint 集成到工作流程的各个方面。

如果您能想到任何其他您想扩展 stylelint 的方法，请告诉我们！

常见问题解答

您脑海中可能还有一些问题。以下是我们被问到的最常见问题的答案。

我可以在 SCSS 中使用 stylelint 吗？或者 Less？

是的，您可以在 SCSS 中使用 stylelint！Less 支持也刚刚到来！由于 PostCSS 允许 自定义解析器，stylelint 可以轻松地支持各种非标准语法——任何您可以为其编写 PostCSS 解析器的语法。

现在，有用于 SCSS、Less 和新的 SugarSS 的 PostCSS 解析器——因此也支持 stylelint。如果您希望现在支持其他自定义语法，请参与编写 PostCSS 解析器！

当然，某些规则可能会在非标准语法的某些方面上遇到问题（例如，将 Sass 的 #{$interpolation} 误认为是 id 选择器）。因为 stylelint 试图覆盖我们样式表的分裂格局——有些人使用标准 CSS，有些人使用 SCSS 等扩展语言，有些人使用奇怪的自定义属性等等——总会有需要填补的空白。但我们一直在解决这些错误，同时，任何规则都可以完全关闭，或者在每个样式表或逐行基础上禁用。

我可以在将来的 CSS 语法中使用 stylelint 吗？

是的！实际上和上面的答案一样：stylelint 可以理解 PostCSS 理解的一切，这肯定包括您正在启用的任何未来的 CSS 语法（可能通过 PostCSS 插件）。事实上，stylelint 的一些规则专门针对未来的 CSS，例如范围特性和自定义属性。

stylelint 配置可能很大。我应该从哪里开始？

我们建议您通过以下三种方式之一构建您的配置。

• 扩展已发布的配置。我们维护 stylelint-config-standard，为大多数用户提供坚实的基线。并且已经发布了许多其他配置。
• 从头开始，一次添加一条规则。默认情况下没有启用任何规则，因此通过自己添加每个规则，您将确切地知道正在执行什么，并将在添加和配置规则时了解每个规则。
• 复制粘贴 这个入门配置，然后决定使用哪些选项以及删除哪些规则。

值得庆幸的是，您不必一遍又一遍地编写大型 stylelint 配置。创建一个适合您口味的配置，并在所有可能的地方使用它。

运行 stylelint 的最简单方法是什么？

对于大多数人来说，运行 stylelint 最简单、最好的方法是通过它的 CLI。

如果您更喜欢 gulp 插件，请尝试使用 gulp-stylelint。对于 webpack，有 几种可能性。我们希望这些插件能激励人们为其他任务运行器（如 Grunt）开发 stylelint 插件。（如果您正在寻找一个简单易行的开源机会！）

您也可以将 stylelint 作为 PostCSS 插件运行，将其包含在任何 PostCSS 运行器的插件链中。这意味着您可以在任何可以使用 PostCSS 的地方使用 stylelint——涵盖了几乎所有现有的编译工具！

此外，已经为 Atom、Sublime Text 和 VS Code 提供了 stylelint 文本编辑器插件——在您工作时提供最快的反馈。有关这些插件和其他插件，请查看 stylelint 网站上的 补充工具 列表。

以下是您在命令行中可以看到的内容

以下是它在 Atom 中的样子

stylelint 会修复我的错误吗？

不会，但另一个名为 stylefmt 的项目旨在做到这一点。它采用 stylelint 配置——与您用于代码 linting 的配置相同——并修复它可以修复的任何错误。我们希望，随着社区的贡献，stylefmt 会不断发展，直到它能够自动修复尽可能多的 stylelint 规则违规行为。 帮助他们！

更新：stylelint 现在有一个 --fix 标志 用于自动修复问题。

您也可以使用其他工具，例如 perfectionist，与 stylelint 结合使用，自动修复可以修复的部分，并自动执行其余部分。

用代码 linting 补充纪律

良好的 CSS 具有非凡的纪律性。这就是为什么我们花费大量时间讨论 SMACSS、ACSS、BEM、SUITCSS、ITCSS 等方法的原因。我们都知道，写得很差的 CSS 非常容易，所以在我们自己的工作中，我们需要制定一个明智的策略，并坚持不懈地坚持下去，这样我们才能编写不会让我们下周感到反感的样式表。

stylelint 的宏伟目标是通过自动执行来补充我们的纪律——提供一组核心规则和一个可插入框架，CSS 作者可以使用它来执行自己的策略。

试试看，告诉我们它对您有什么作用。如果您有改进的想法，请参与进来！贡献规则、增强功能、测试、错误修复、文档、新想法，或者只是反馈。所有级别的开发人员都有工作要做。