По мере развития фронт-энда использование инструментов для оценки качества кода существенно возросло.
Это, пожалуй, наиболее очевидно при взгляде на экосистему JavaScript. Использование JavaScript-линтера теперь является ожидаемым стандартом для разработчиков переднего плана, чтобы гарантировать, что их код хорошо структурирован и согласован. Фактически, в моем недавнем обзоре инструментов, подавляющее большинство разработчиков заявили, что они используют свой JavaScript .
Когда дело доходит до написания CSS, стремление к использованию инструментов качества кода было немного медленнее, и большинство разработчиков в том же опросе заявили, что они решили не использовать линтер CSS в своем рабочем процессе .
Сегодня я хочу устранить этот недостаток, рассматривая один конкретный инструмент, который поднял планку, когда дело доходит до раскрашивания таблиц стилей: stylelint .
Стоит отметить, что хотя в этой статье я упоминаю CSS, эти ссылки взаимозаменяемы с языком предварительной обработки, таким как Sass. Stylelint может оценивать файлы Sass и Less, а также обычный CSS, и мы рассмотрим это более подробно позже в этой статье.
(Очень) Краткая история CSS Linting
Когда CSS linting впервые была представлена как концепция, она была довольно поляризованной. Вскоре после того, как CSS Lint был представлен еще в 2011 году, я помню, как читал статью Мэтта Уилкокса под названием « CSS Lint — это вредно» , в которой критиковался самоуверенный характер некоторых из его правил — мнение, разделяемое многими в сообществе.
Оглядываясь назад, CSS Lint был очень похож на первые доступные инструменты JavaScript для линтинга, такие как JSLint — упрямый и не очень гибкий. Однако, несмотря на то, что такие инструменты, как JSHint и ESLint, появились и подтолкнули JavaScript к слинированию, альтернатив в CSS-ландшафте слияния не было.
Пока стильлинт не появился на сцене.
Почему Stylelint?
Есть несколько причин, по которым я считаю, что stylelint — лучший инструмент, доступный для раскрашивания CSS.
Во-первых, это совершенно неконтролируемое. Это означает, что вы можете включить столько правил, сколько вам нужно, с рядом правил, которые дают вам возможность настроить их в соответствии с вашими предпочтениями.
Кроме того, у него есть огромный набор доступных правил — фактически более 150 , не включая языковые правила для специфического синтаксиса препроцессора. Потратив немного времени на их изучение, вы сможете создать набор правил, который соответствует вашим стилям.
Он также очень гибкий, понимает CSS и CSS-подобный синтаксис, такой как SCSS и Less. Так что, хотите ли вы скопировать код препроцессора или ванильный CSS, stylelint поможет вам.
Наконец, и, возможно, самое главное, его документация превосходна. Хотите узнать, какие правила доступны? Ознакомьтесь с подробной документацией, охватывающей все доступные правила . Как насчет совета о том, как внести новое правило, которое вам может понравиться? У них есть отличное руководство для разработчиков, чтобы помочь вам с этим.
Что может сделать Stylelint?
Ценность добавления шага задержки при разработке на любом языке заключается в улучшении согласованности кода, который вы пишете, и уменьшении количества ошибок в вашем коде.
При применении этого к CSS существует ряд проблем, с которыми stylelint может помочь вам решить.
Синтаксические ошибки
Синтаксические ошибки не являются субъективными ошибками и должны быть очень четкими после выделения.
Рассмотрим следующий пример:
.element { color: #EA12AE1; disply: block; } Приведенный выше код показывает две разные синтаксические ошибки. Первая ошибка — неправильный шестнадцатеричный цвет. Вторым является опечатка при объявлении свойства display .
Это довольно простые синтаксические ошибки, которые могут быть обнаружены при помощи стиля, используя такие правила, как color-no-invalid-hex и property-no-unknown , избавляя вас от головной боли, связанной с поиском ошибки вручную.
Форматирование и согласованность
В CSS предпочтение стиля кода может быть чрезвычайно субъективным. Скорее всего, мне нравится писать свой CSS, а не то, что вы предпочитаете писать свой. Поэтому важно, чтобы CSS-линтер мог адаптироваться к вашим предпочтениям, а не пытаться навязать вам набор правил.
Рассмотрим следующие стили:
.listing { display: block; } .listing-item { color:blue; } .listing-img{ width : 100%} .listing-text { font-size: block; } .listing-icon { background-size: 0, 0; }
Все наборы правил выше содержат действительный CSS, но они явно не соответствуют друг другу по стилю. Использование пробелов в каждом объявлении отличается, и каждый блок форматируется немного по-другому.
Этот пример показывает только несколько возможных способов форматирования CSS. Но на самом деле существуют сотни тонких изменений. По всей таблице стилей (или нескольким файлам) такие несоответствия могут ухудшить удобочитаемость и удобство сопровождения вашего кода.
Это несоответствие становится более очевидным, когда над проектом работают несколько разработчиков, поскольку каждый из них может предпочесть писать свои стили немного по-своему. Всегда полезно собраться вместе и согласовать набор правил форматирования, которых вы все будете придерживаться в такой ситуации.
Stylelint позволяет настроить набор правил в соответствии с тем, как вы или ваша команда предпочитаете форматировать свои стили. Независимо от ваших предпочтений, stylelint может проверить, что эти правила применяются последовательно в вашем проекте.
Уменьшить дублирование в стилях
Дублирование может быть проблемой для отладки, будь то дублирование селекторов или свойств в таблице стилей.
Взгляните на следующий CSS:
/* Property duplication */ a { display: block; color: orange; font-size: 1.2rem; display: inline; /* duplicate */ } /* Selector duplication (1) Same selector, at different points in stylesheet */ .foo {} .bar {} .foo {} /* Selector duplication (2) The same group of selectors, simply ordered differently */ .foo, .bar {} .bar, .foo {}
У Stylelint есть несколько правил, которые могут помочь обнаружить такой тип дублирования в вашем коде, например, правило declaration-block-no-duplicate-properties которое будет перехватывать повторяющиеся свойства.
Он также может быть настроен на игнорирование преднамеренного дублирования, например, когда одно и то же свойство было определено для предоставления запасного значения:
.example { font-size: 14px; font-size: 1.2rem; /* will override the above if browser supports rem */ }
Проверки передовой практики
Лучшие практики в CSS несколько субъективны, но stylelint дает вам полную гибкость в том, как вы хотите проверить эти «ошибки», если они вообще есть.
Одна из общепринятых лучших практик, попадающих в эту категорию, заключается в выдаче ошибки при превышении определенной глубины вложенности селектора при написании кода препроцессора. Это полезно, чтобы гарантировать, что уровень специфичности ваших стилей поддерживается на разумном уровне и не выходит из-под контроля.
Разные разработчики и разные варианты использования означают, что то, что считается «приемлемым», может меняться от проекта к проекту. Например, у вас может быть устаревшая таблица стилей, в которой вы хотите, чтобы глубина вложения не ухудшилась. Правило max-nesting-depth позволяет вам определить собственную приемлемую глубину вложения, чтобы проверить, что означает, что это правило может быть полезно для любого проекта, который использует препроцессор.
Ограничить языковые возможности
Последний набор проверок, к которым у вас есть доступ к stylelint, — это то, что они называют «Ограничить языковые функции» в руководстве по правилам. Они могут использоваться для обеспечения соблюдения ваших собственных правил при работе с таблицами стилей.
Типичным примером будет использование такого инструмента, как Autoprefixer, для автоматизации добавления префиксов поставщиков в ваши стили. В этом случае было бы полезно выдать предупреждение или сообщение об ошибке, если префикс поставщика был добавлен разработчиком вручную, поскольку это поможет защитить код от ненужных префиксов, которые будут добавлены при последующем запуске инструмента. нефиксированные стили. Stylelint может позаботиться об этом за вас с помощью правила «value-no-vendor-prefix» , которое именно это и делает.
Другие примеры правил варьируются от запрета именованных цветов или определения максимальной точности чисел до возможности занести в черный список определенные свойства, если вы того пожелаете.
Эти правила более самоуверенны по своей природе, но вы можете использовать их по своему усмотрению. Это означает, что правила оформления ваших проектов адаптированы к тому, как вам и вашей команде нравится писать свои стили.
Использование Stylelint
Мы рассмотрели, что может делать stylelint, но насколько легко его настроить и использовать?
Как и его набор правил, stylelint чрезвычайно гибок. Существует ряд доступных плагинов, которые облегчают интеграцию в любой инструмент сборки, который вы предпочитаете использовать, а также плагины редактора для Atom, Sublime Text и Visual Studio Code.
С точки зрения настройки вашего собственного набора правил, есть несколько способов сделать это . Самый простой способ — создать файл .stylelintrc в корневом каталоге вашего проекта, внутри которого вы можете начать создавать свои собственные правила, такие как:
{ "rules": { 'block-closing-brace-newline-before': 'always-multi-line', 'block-closing-brace-space-before': 'always-single-line', 'color-no-invalid-hex': true, 'comment-no-empty': true, 'unit-case': 'lower', 'unit-no-unknown': true, // etc... } }
Когда вы затем запускаете задачу stylelint — например, как часть вашей сборки Gulp или webpack — она подберет описанную выше конфигурацию и использует эти правила для привязки ваших стилей.
Подобно инструментам JavaScript, таким как ESLint, вы также можете использовать существующую конфигурацию в качестве отправной точки и добавлять свои собственные правила. Stylelint имеет рекомендованную базовую конфигурацию, которую вы можете расширить, или вы можете выбрать расширение из более надуманных наборов правил, основанных на таких методологиях, как SUIT CSS .
Мой совет — потратить немного времени на просмотр доступных правил и создание конфигурации, которой вы и ваша команда довольны. Оказавшись полезным, вы можете сделать еще один шаг, сделав свою конфигурацию доступной в виде устанавливаемого модуля npm — например, расширяемых наборов правил, упомянутых выше, — чтобы затем вы могли установить и поддерживать синхронизацию конфигурации stylelint со всеми вашими проектами.
Linting код препроцессора
Как я упоминал ранее, stylelint может задерживать Sass или Less так же легко, как и CSS.
Настройка этого зависит от того, как вы используете stylelint. Если вы используете плагин для инструмента сборки, такого как Gulp или webpack, вы можете передать значение для syntax опции stylelint. Эта опция принимает less или scss качестве значений в зависимости от того, какой синтаксис вы хотите использовать.
Например, чтобы указать, что вы хотите .scss ваши файлы .scss , вы должны передать следующий объект в качестве параметров stylelint:
{ syntax: 'scss' }
Если вы хотите узнать больше о том, как вы можете использовать stylelint для кодирования кода препроцессора, в его документации есть большой раздел, посвященный именно этому.
Вперед и Линт!
Как вы можете видеть, stylelint значительно продлил CSS-линтинг за относительно короткое время. Его гибкость и широта правил означают, что вы можете настроить конфигурацию, которая будет настолько подробной или простой, как вам захочется, что поможет вам сделать ваши стили более согласованными, поддерживаемыми и свободными от ошибок.
Я надеюсь, что все больше разработчиков захотят использовать такой отличный инструмент; так что попробуйте взять его на спин. Ваши таблицы стилей будут вам благодарны.