Дэвид Кларк - один из создателей Stylelint - инструмента, позволяющего навести порядок в CSS. Он написал превосходное вступление о том, зачем нужно линтить CSS.

Вы пишете CSS. Возможно, очень много. И вы допускаете ошибки. Возможно, тоже очень много. Миру нужен новый герой, который спасёт нас от ошибок в CSS!

Распознающий ошибки механизм - вот что нам нужно

Нам нужен надёжный, распознающий ошибки механизм, который понимает CSS и понимает наc: наши намерения, предпочтения, идеалы и слабости.

Конечно, как у всех подобных вещей, у такого механизма будут свои ограничения. Но эти ограничения будут отличаться от тех, которые стоят перед вами и вашими коллегами. Он будет предотвращать все ошибки, которые только сможет, и будет это делать последовательно и неустанно. Тем временем вы можете сосредоточиться на улучшении самого механизма, увеличивая его возможности и ослабляя ограничения. Если подобный проект будет открытый, CSS-разработчики со всего мира смогут сделать свой вклад, поделившись информацией о своих ошибках.

CSS-разработчикам нужны линтеры, как и всем остальным

Программы, предотвращающие ошибки, называются «линтерами». Для JavaScript уже есть несколько хороших линтеров. В частности, ESLint просто творит чудеса, показывая всем нам, насколько хорош может быть линтер. Но в мире CSS всё было плохо - мы были ограничены несколькими вариантами: написанным на Ruby препроцессорным scss-lint и старым CSS Lint.

Но всё это было до прихода PostCSS. PostCSS, в числе прочего, помогает создавать совместимые друг с другом инструменты работы с CSS. Он может распарсить любой CSS-подобный синтаксис в Абстрактное Синтаксическое Дерево (AST, Abstract Syntax Tree), с которым в дальнейшем и работают плагины. При помощи специальных парсеров PostCSS может обрабатывать даже нестандартные, технически «невалидные» шаблоны (например, комментарии через //).

Таким образом, созрела почва для нового мощного CSS-линтера - основанного на PostCSS и вобравшего в себя лучшие стороны scss-lint и ESLint.

В этом проекте я работал с несколькими коллегами, и сейчас я хочу представить вам то, что мы создали - Stylelint.

Несколько вещей, которые можно делать с помощью Stylelint

Находить ошибки

Некоторые правила Stylelint служат для обнаружения очевидных ошибок: опечаток или описок, сделанных, когда вы спешили или были невнимательны. Например, вы можете запретить пустые блоки в коде, неверные hex-значения, дублирующиеся селекторы, необъявленные анимации, неправильный синтаксис линейных градиентов.

Другие правила предназначены для отлова более сложных ошибок. Например, есть правило, которое срабатывает, когда вы использовали сокращенное написание свойства (например, margin), перекрывающее один из его развернутых вариантов (например, margin-top), хотя вы, скорее всего, не хотели этого. А ещё есть правило, которое срабатывает в такой ситуации: представьте, что Правило А находится до Правила Б, однако при этом перезаписывает Правило Б, поскольку селектор у Правила А более специфичен (например, Правило А объявлено в .foo.bar {...}, а Правило Б в .foo {...}). Это вам не хухры-мухры.

Ещё одно правило использует PostCSS-плагин doiuse, проверяя, будут ли ваши стили работать для всех браузеров, которые вы решили поддерживать. Другое правило использует css-colorguard, чтобы сравнивать используемые в проекте цвета, и спрашивать вас, не стоит ли использовать единый цвет вместо нескольких похожих. (Вы уже заметили, что Stylelint использует одно из главных преимуществ PostCSS? Довольно просто сделать правила, использующие результаты работы других PostCSS-плагинов).

Навязывать лучшие практики

Если вы следуете определённой методологии при работе со стилями или имеете определённый стиль кода, должна быть возможность не принимать некоторые конструкции кода. Stylelint предоставляет вам такие возможности.

Более того, вам нужно контролировать свои селекторы. Беспощадно. Используя Stylelint, вы можете запретить селекторы, превышающие заданную специфичность, или, наконец, положить конец глубокой вложенности селекторов. Вы можете запретить использование некоторых категорий селекторов (например, id) и составить регулярные выражения, проверяющие, что селекторы следуют соглашениям по именованию.

Вы можете запретить использование !important или браузерных хаков, не относящихся к тем браузерам, что вы поддерживаете. Если вы используете Автопрефиксер (что вы, пожалуй, должны делать), вы можете запретить использование браузерных префиксов в исходных файлах.

Если же вы хотите чего-то посерьёзнее, посвятите некоторое время настройкам, и вы сможете задавать порядок свойств в своих правилах, создавать черные и белые списки правил, значений, функций и единиц измерения.

Навязывать стиль написания кода

В Stylelint есть куча правил, которые автоматически навязывают соглашения по стилю кода, так что ни вы, ни ваши коллеги не должны этим заниматься. Мы постарались сделать эти правила максимально полными и невероятно гибкими.

Большинство из этих правил связаны с отступами. Однако, есть и такие, которые проверяют типы кавычек, постановку прописных и строчных символов, подстановку нуля в дробных значениях, использование сокращенных/полных правил и т.д.

Задумка в том, что вы с коллегами можете один раз договориться о стиле кода (например, «А давайте всегда ставить пробел после двоеточия в объявлениях правил»), занести это в конфигурацию Stylelint и больше об этом не вспоминать. Пусть машины страдают за вас!

Настраивать и расширять всё что угодно

Nicholas Zakas, создатель ESLint (и также CSS Lint), написал, что секрет успеха ESLint в его расширяемости. Stylelint следует примеру ESLint и старается быть настолько расширяемым, насколько это возможно.

Если вам не нравятся встроенные в Stylelint инструменты вывода, вы можете создать собственные, и даже адаптировать их для вашей организации. Также вы можете настроить оповещения, выводимые правилами.

Дисциплинируйте себя при помощи линтинга

Существует невероятное количество правил написания CSS. Все мы знаем, что очень просто написать плохой CSS, поэтому мы и уделяем так много времени разговорам о методологиях (SMACSS, ACSS, BEM, SUITCSS, и т.д.). Вы должны выбрать стратегию и упорно придерживаться её. Если, конечно, вы не хотите писать код, от которого будете морщиться уже через неделю.

Амбициозная цель Stylelint - автоматизировать правила написания кода. Это позволит создать некий костяк правил и инфраструктуру, которые CSS-разработчики смогут внедрить в работу, чтобы улучшить свои собственные практики.