使用 stylelint检查CSS_StyleLint

使用 stylelint检查CSS_StyleLint

当你书写大量的css代码时，可能会出现不止一个的错误。可能需要某个工具来阻止你CSS书写的错误。

可能，有的时候你的错误真的是一个bug。也有可能仅仅因为草率造成的不一致或者不明确的代码风格。可能它们当中的许zVySg多看起来微不足道(取决于你的性子)，但是随着代码库的增多以及时间累积，许多人使用时就会做出有丑陋的东西。事情的后果不是你可以想象的。

你尝试去控制自己。你的同事也帮助你，当你游离及时纠正你的错误。但是，你和你的同事都是错误的制造者，所以最后至少在一定程度上都不可避免的失败了。后来，你或者其他人就要解决你页面CSS错误造成的问题。

无论是你或者你同事都不喜欢讨论你犯下的错误，因为这是令人尴尬的事情。甚至有时会令人沮丧或者产生情感破裂。一定的规范有时候对于代码库的维护是有帮助的，如一致的书写风格，可能当手动执行时，看起来有点迂腐乏味。不然它们就会将你平时喜欢的爱出风头，固执的元素展现出来。

另外你可能更喜欢可以及时修正错误，而不是等待代码审查后由别人指出错误后，自己进行修改并声明自己不会再出现此类错误。当你的CSS出现错误时，一个及时的反馈会帮助你节省很多时间。

你所需要的是一个防止错误产生的机器

你需要一个防止错误产生的机器，可以理解CSS并且理解你:你的意图、喜好、主意以及弱点。

我们将这些防止错误出现的程序称为"linters"。javascript中有几个比较好的linter。尤其是ESLint，它起到的作用如奇迹般，向我们展示了一个好的linter是如此的有用。但是在CSS中，我们就没有这么幸运了，我们的选择十分有限: 基于Ruby的，具有特殊预处理程序的scss-lint和较早的CSS Lint。

但是这都是在PostCSS出现之前。除此之外，PostCSS提供了一些方法，建立更具有良好交互性的CSS工具。它可以将任何类CSS语法解析为抽象语法树(AST)的插件，从而进行分析以及操作。并且利用自定义解析器，PostCSS甚至可以处理不规范的无效模式(如//注释)

成熟的条件已经可以产生一个具有更强大功能的linter -- 基于PostCSS的强大功能以及在scss-lint和ESLint最佳功能的启发之下。

我和几个小伙伴一起致力于这个项目，现在我就要开始介绍一下我们开发的工具: stylelint.

使用stylelint你可以做的事情

以下是尝试于stylelint的功能总结，其中规则多达百余条，并且具有可扩展性。

在这一点，如果你发现自己已经变得有点不耐烦("Ok,Ok:我相信stylelint将具有奇迹般的工作效果。不需要过多的总结。")。仅仅跳到下一部分，在这里我仅仅说明一些问题并提供一些提示。

错误捕获

有些stylelint规则旨在找出明显的错误，如拼写错误或者由于你的心烦意乱或者睡眼惺忪时制造的疏漏。例如，你可以禁止空白块，无效的十六进制值，重复的选择器，未命名的动画名称和错误的线性渐变的语法。

其它的规则都是尽自己最大的努力捕捉更细微的错误。这里有一条规则: 当你使用可以覆盖其属性同行(如 margin-top)的速记属性时(如 margin)，就会发出警告，因为这可能是由于你的疏忽造成的。另外，还有一种规则会警告你:当出现混乱局面时，如规则Ａ出现在规则B之前，但是实际上覆盖了规则B，因为规则A的的选择器具有更高的优先级(如，规则A为 .foo.bar{}，规则B为 .foo{})。这是一种十分棘手的情况。

还有一种规则使用了PostCSS的doiuse插件，用于检查你的浏览器是否支持此样式。另外一种则使用了css-colorguard插件用于提示颜色的相似性，以免造成你的混乱使用。(请注意: 这是基于PostCSS之上的stylelint的主要优势之一：相比于其它PostCSS 插件，用很少的努力，stylelint就可以进行提示。)

强制执行最佳实践

如果你在样式表中使用了系统方法，或者对你的代码设置了一个样式指南，你应该取缔这些模式了。stylelint已经提供了这些功能。

首先，你需要狠狠地控制你的选择器。使用stylelint，你可以禁止超过一定特异性的选择器或者在嵌套深度上设置限制。你可以禁止类别选择器(例如没有 id的选择器），并对其余的选择器使用正则表达式进行命名约定。

你可以禁止!important的使用，或者你的浏览器并不支持的brower hacks。如果你使用Autoprefixer(或者说你应该使用),你可以禁止在源样式表中使用供应商前缀。

如果你想要更加严谨 -- 你可以花费一些时间在配置上，以保证绝对的一致性 -- 你可以强制执行样式表属性的顺序，并为黑名单，白名单提供属性，值，函数还有单位。

执行代码样式的约定

stylelint具有自动执行代码样式的约定，所以你和你的队友无需主动设置。我们致力于使这些规则更加全面灵活。

这些规则主要针对于空格，但是同样针对于其它的细节，如；引号，大小写字母，在小数前写零，使用关键字以及拼读出值等等。

梦想你和你的队友可以建立一个格式约定(例如我们始终在声明冒号之后留有一个空格)，并在你的stylelint配置中进行修改，之后你们就不会为此再次讨论。让其执行于机器王国。

制定以及扩展一切

你可以书写并且发布自己的规则插件。现在已经具有了一大堆可以使用的;并且我们渴望看到别人的优秀插件。

配置是可扩展的，因此可以共享。至于插件，我们从ESLint了解了这一功能的价值性。检查其中包括WordPress和SUITCSS配置的，并且已经公布的。

如果你不喜欢 stylelint 的内置提示，你可以手工创建属于你自己的风格，甚至可以为你的组织进行创建。你还可以自定义用于提供警告信息的规则。

使用stylelint的API，你可以创建文本编译器的插件，并进行测试使stylelint 融入到你的工作流的每个方面。

如果你有关于stylelint扩展的想法，请让我们知道！

预期问题的答案

在你的心中可能存在几个疑问。这里有几个最为常见问题的解释:

是否可以在SCSS或者Less中使用stylelint？

答案是肯定的，你可以在SCSS中使用stylelint，并且在Less中也得到了支持！自从PostCSS允许自定义解析器，stylelint可以很轻松的支持各种各样的非标准语法 - 你可以自定义一个PostCSS解析器进行解析。

正因为PostCSS解析器 -- 因此stylelint支持SCSS，Less以及新SugarSS。如果你想要实现另外一个自定义语法的支持，你可以通过PostLess得以实现！

当然，还有一定的规则在你的非标准语法面前得到羁绊(如迷惑于Sass id选择器的 #{$interpolation})。因为stylelint试图掩盖我们样式表的样式 - 一些人使用标准CSS，一些人使用扩展语言如SCSS，一些人使用一些怪异的自定义属性等等 - 这些难免都会产生一些漏洞需要去填补。但是，我们一直在处理我们找到的这些错误；在此期间的任何规则可以完全被关闭或者逐次样式表或者逐次行的进行禁用。

stylelint是否可以使用未来CSS语法？

是的！类似于上面所述的答案: stylelint可以理解PostCSS所理解的任何东西，包括启用未来任何的CSS语法(可能通过PostCSS插件)。事实上，一些stylelint规则专门处理未来CSS语法和一些自定义属性。

stylelint配置是巨大的，我应该从哪儿开始呢？

我们建议三种配置方式:

扩展一个发布的配置。我们维持stylelint-配置标准，以便于为用户提供一个固有的基准。并且许多的配置也已经公布。从头开始，一次添加一条规则。默认情况下，没有一条规则被开启，所以通过手动添加规则你就会知道哪一个会被强制执行，并且可以理解你添加的每条规则。启动复制粘贴配置，决定使用哪些选项并选择性进行删除。

值得庆幸的是，你不需要一遍又一遍的书写巨大的stylelint配置。你可以选择一个你喜欢的风格并且可以在任何地方使用它。

运行stylelint最简单的方式？

对于大多数人而言，最简单的方式就是通过它的命令行。

如果你更偏爱gulp插件，你可以使用gulp-stylelint。对于webpack，这里有很多选择的可能性。我们希望这些插件可以激励你们创建其它的stylelint插件，例如，适用于Grunt的插件。(你可以在开源项目中去寻找！)

你也可以使用PostCSS 插件运行stylelint，包括插件中所包含的任何东西。这就意味着你可以在任何可以使用PostCSS(几乎涵盖于每一个编译工具)的地方使用stylelint！

此外，这里也存在一个适用于Atom，Sublime Text，VS Code的stylelint文本编译插件，以提供最快的反馈。关于更多信息，请查阅 stylelint 网站上的互http://补工具列表。

如下所示，在命令行中，你所期待看到的结果:

在Atom中显示如下；

stylelint是否可以修补我的错误？

不，但是另外一个叫做stylefmt旨在做到这一点。它需要一个stylelint配置 - 十分类似于你在linting使用的 - 并且可以修复任何错误。我们希望随着社区人员的贡献，stylelint可以发展到自动修补违反stylelint规则的错误。请帮他们实现这个目标！

你也可以使用其它的工具，例如CSScomb或者与stylelint联合使用的perfectionlist，自动修复并自动强制休息。

使用linting进行约束补充

在良好的CSS中有巨大数额的约束。这就是为什么我们花费大量的时间讨论 SMACSS, ACSS, BEM, SUITCSS, ITCShttp://S等等的方法。我们都知道书写糟糕的CSS是十分容易的，所以，如果让我们不再畏惧于CSS样式的书写，我们需要在工作中建立一个智能化的战略并勇敢的坚守下去。

试一试，让我们知道如何为你提供服务。如果你有相关更好的改进想法，如贡献规则、 增强功能、 测试、 修复bug、 文件、 新想法或只是反馈，请给我们提出！这样我们所有级别的开发人员就有工作做了。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。