Java, UX, HTML, CSS, WEB-design

Stylelint: линтер таблицы стилей, которого мы всегда хотели


  • Алекс Худоченков

  • 0 Комментарии

Stylelint: линтер таблицы стилей, которого мы всегда хотели

  • 10 минут чтения

  • Кодирование, инструменты, JavaScript, методы

Краткое резюме ↬

Мы узнаем, почему linting таблицы стилей имеет значение, как stylelint наводит порядок в таблице стилей и как мы можем избежать ошибок.

Всем нужна чистая, непротиворечивая кодовая база, независимо от языка. Разработчики привыкли настраивать линтеры в таких языках программирования, как JavaScript и Python, но редко используют линтеры для таблиц стилей. В этой статье мы рассмотрим stylelint, линтер для таблиц стилей.

Мы узнаем, почему linting таблицы стилей имеет значение, как stylelint наводит порядок в таблице стилей и как мы можем избежать ошибок. Наконец, мы научимся использовать stylelint и как можно скорее начнем его.

Дальнейшее чтение на SmashingMag:

  • Почему стиль кодирования имеет значение
  • 7 принципов чистого и оптимизированного кода CSS
  • ESLint: JavaScript-линтер следующего поколения
  • Введение в PostCSS

Почему линтинг важен

Линтер — это инструмент, анализирует код и сообщает об ошибках когда часть кода не проходит правила, определенные в конфигурации линтера.

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

Еще после прыжка! Продолжить чтение ниже ↓

Конечно, у вашей команды могут быть правила стилей кода, написанные открытым текстом где-нибудь в какой-нибудь вики. Но всегда нужно учитывать человеческий фактор: люди совершают ошибки — никогда не намеренно.

И даже если вы одержимы соблюдением правил правильного стиля кодирования, ваши коллеги или участники вашего проекта с открытым исходным кодом могут этого не делать. Без линтера вам пришлось бы самостоятельно проверять код на стили и ошибки. Никто не должен тратить время на то, что можно автоматизировать. Линтер значительно сократить время, затрачиваемое на код-ревью потому что вы не будете тратить время на проверку стилей и написание кучи комментариев по поводу каждой ошибки. Вы сможете изучить, что делает код, а не то, как он выглядит.

Стайлинт

Stylelint — мощный современный линтер таблиц стилей, написанный на JavaScript Дэвидом Кларком, Ричардом Хэллоусом, Evilebot Tnawi и сообществом. Он силен своей скоростью, разнообразием и качеством правил. совершенно непредвзятый. В Stylelint более сотни правил, и их число растет. Однако не бойтесь: по умолчанию все правила отключены, и вы включаете только те, которые хотите. Stylelint может анализировать не только CSS, но и Sass, SugarSS и любой другой синтаксис, который может разобрать PostCSS (поскольку stylelint основан на нем).

Stylelint для таблиц стилей — то же, что ESLint для JavaScript.

Правила

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

Я не буду здесь останавливаться на правилах стиля (их масса). Скорее, я хочу описать некоторые правила, которые помогают с ремонтопригодностью и предотвращают ошибки.

Правило, запрещающее сокращенным свойствам переопределять другие объявления (или, на языке stylelint, declaration-block-no-shorthand-property-overrides) предотвратит такую ​​ситуацию:

div {
    padding-left: 20px; /* This property is overridden. */
    padding: 10px;
}

Stylelint также предотвращает недопустимые цвета HEX (color-no-invalid-hex):

p {
    color: #44;
}

И это предотвращает дублирование свойств (declaration-block-no-duplicate-properties):

p {
    color: #000; /* This property is overridden. */
    margin: 0 0 1.25em;
    color: #777;
}

Вы можете использовать старый синтаксис для градиентов. Stylelint проверит это (function-linear-gradient-no-nonstandard-direction):

/* incorrect property */
.block {
    background: linear-gradient(bottom, #fff, #000);
}

/* correct property */
.block {
    background: linear-gradient(to bottom, #fff, #000);
}

С помощью !important ключевое слово в свойстве может вызвать проблемы в будущем, когда вам нужно переопределить свойство другим правилом. Просто избегайте !important вместе с declaration-no-important правило.

Использование идентификатора в селекторе (#main) и с помощью селектора типа (т. е. селектора, основанного на элементе HTML, например, .block p) могут быть запрещены в вашей методологии разработки (например, БЭМ). В таком случае, selector-no-id и selector-no-type пригодиться.

Иногда вы что-то делаете с ошибкой или забываете добавить что-то в таблицу стилей. В случае с анимацией no-unknown-animations сообщит, если имя анимации не имеет соответствующего @keyframes правило.

И зачем вам возиться с префиксами в значениях, именах свойств и селекторах, когда у нас есть Autoprefixer? Пусть Autoprefixer позаботится об этом и предотвратит добавление префиксов с помощью правил. value-no-vendor-prefix, property-no-vendor-prefix и selector-no-vendor-prefix.

Конечно, в stylelint есть еще много правил.

Плагины

Помимо правил по умолчанию, stylelint также поддерживает плагины, так что вы можете расширить его с помощью новых правил. На данный момент доступно не так много плагинов, но те, которые у нас есть, очень удобны.

Иногда разработчики перестраховываются. Хотя все препроцессоры поддерживают вложенность, очень глубокая вложенность правил приводит к повышенной специфичности селекторов и приводит к проблемам с поддержкой этих правил. Вот типичный пример:

.header {
    .nav {
        .item {
            .link {
                color: blue;

                &:hover {
                    color: red;
                }
            }
        }
    }
}

Это выглядит следующим образом:

.header .nav .item .link {
    color: blue;
}
.header .nav .item .link:hover {
    color: red;
}

В Stylelint нет правила для этой проблемы из коробки, но есть плагин (stylelint-statement-max-nesting-depth), который добавляет правило глубины вложенности.

Чтобы использовать любой плагин, сначала установите его:

npm install stylelint-statement-max-nesting-depth --save-dev

Затем добавьте плагин в файл конфигурации в plugins множество. Добавьте новое правило и настройте его:

{
    "plugins": [
        "stylelint-statement-max-nesting-depth"
    ],
    "rules": {
        "statement-max-nesting-depth": 2
    }
}

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

.nav {
    .link {
        color: blue;

        &:hover {
            color: red;
        }
    }
}

Или мы могли бы еще упростить до одного уровня:

.nav-link {
    color: blue;

    &:hover {
        color: red;
    }
}

Я не буду здесь перечислять все плагины, а порекомендую несколько:

  • Запретить квалифицированные селекторы, такие как ul.nav, div#main и input[type="submit"]. (Каждый параметр можно включить отдельно.)
  • По возможности применяйте сокращенные значения.
  • Если вы следуете методологии BEM или SUIT, вы можете проверить правильность своих селекторов по ним. Плагин stylelint-selector-bem-pattern имеет предопределенные шаблоны для BEM и SUIT и может быть настроен для других методологий.

Если вы хотите новое правило, вы можете написать свой собственный плагин.

Файлы конфигурации

Настройка — самая сложная часть использования линтера и самая трудоемкая. Но есть ярлыки и различные стратегии, облегчающие настройку stylelint.

Ваша конфигурация может стать очень большой, поэтому наиболее удобным способом хранения конфигурации stylelint является отдельный файл JSON с именем .stylelintrc. Таким образом, файл можно использовать в интерфейсе командной строки, в инструменте сборки и в редакторе кода.

Очень простая конфигурация может выглядеть так:

{
    "rules": {
        "color-hex-case": "lower",
        "color-hex-length": "short",
        "color-no-invalid-hex": true
    }
}

Есть три стратегии для конфигурации. То первый, простой, заключается в расширении чужой конфигурации (которую поддерживает stylelint), а затем добавлении, отключении или настройке правил, которые вы хотите изменить. Разработчики сделали конфигурацию, которая, вероятно, подходит для большинства нужд. Вы можете установить его как пакет npm:

npm install stylelint-config-standard --save-dev

Затем в своем собственном файле конфигурации вы расширите их и переопределите любые правила по мере необходимости:

{
    "extends": "stylelint-config-standard",
    "rules": {
        "indentation": "tab",
        "number-leading-zero": null
    }
}

В этом примере мы расширили stylelint-config-standard и изменил indentation правило, чтобы быть «вкладки» и отключил number-leading-zero правило.

Вы можете расширять не только общие конфигурации через npm, но и локальные. В документации больше информации о расширении и совместном использовании конфигураций.

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

{
    "rules": {
        "color-no-invalid-hex": true,
        "declaration-block-no-duplicate-properties": true,
        "declaration-block-no-shorthand-property-overrides": true,
        "function-linear-gradient-no-nonstandard-direction": true
    }
}

Позже вы можете добавить больше правил.

То третья стратегия это пройтись по всем правилам и настроить каждое. Я предпочитаю эту стратегию, потому что хочу проверить как можно больше и использовать stylelint на полную мощность. Конечно, это самая трудоемкая стратегия, но она дает наилучший результат. Чтобы упростить задачу, разработчики stylelint создали пример файла конфигурации со всеми правилами.

Каждое включенное правило имеет серьезность ошибки. Это означает, что любое невыполненное правило не пройдет тест. Уровень серьезности для любого правила может быть снижен к предупреждению, которое предотвратит сбой теста. Это полезно, если вы только что ввели правило и не хотите, чтобы сборка потерпела неудачу, пока команда приспосабливается к новому правилу.

{
    "rules": {
        "color-hex-case": ["lower", { "severity": "warning" }]
    }
}

В этом примере stylelint предупредит, если цвет HEX написан неправильно, но не выдаст ошибку.

Иногда нам нужно поместить в таблицу стилей что-то, что запрещает наша конфигурация stylelint. Например, нам запрещено использовать !important ключевое слово, но нам может понадобиться использовать его в одном месте, чтобы переопределить какой-либо сторонний виджет. Мы не хотели бы отключать правило из-за этого исключительного случая. Но мы также не хотели бы видеть ошибку каждый раз. К счастью, мы можем отключить конкретное правило в строке CSS, добавив комментарий:

.widget {
  display: none !important; /* stylelint-disable-line declaration-no-important */
}

Или мы можем отключить stylelint для фрагмента CSS:

/* stylelint-disable */
.third-party-code {}
/* stylelint-enable */

использование

Stylelint можно использовать по-разному: в командной строке, в инструменте сборки (например, Gulp, Grunt или Webpack), в редакторе кода или в качестве хука Git перед фиксацией для поэтапных изменений в репозитории Git. Я сосредоточусь здесь на двух способах.

Командная строка

Использование командной строки полезно, когда вы хотите проверить проект, в котором нет stylelint, или вы хотите использовать stylelint в скрипте npm.

Установите stylelint глобально:

npm install stylelint -g

Затем он будет доступен везде в вашем терминале:

stylelint "styles/**/*.css"

Эта команда проверит все файлы CSS в styles каталог и любой из его подкаталогов.

Чтобы линтинговать файлы SCSS или SugarSS, добавьте syntax вариант:

stylelint "styles/*.scss" --syntax scss

Конфигурационный файл можно указать явно:

stylelint "styles/*.css" --config bar/myStylelintConfig.json

Если он не указан явно, stylelint будет искать .stylelintrc файл в текущем рабочем каталоге.

Глоток

Чтобы использовать stylelint с Gulp, используйте его как плагин PostCSS. Вам потребуется установить следующие пакеты:

npm install gulp-postcss stylelint postcss-reporter --save-dev

gulp-postcss — это средство запуска для всех плагинов PostCSS, а postcss-reporter выводит намного более приятные ошибки и предупреждения из stylelint.

var postcss = require('gulp-postcss');
var reporter = require('postcss-reporter');
var stylelint = require('stylelint');

gulp.task('lint:css', function() {
    return gulp.src('src/**/*.css')
        .pipe(postcss([
            stylelint({ /* options */ }),
            reporter({ clearMessages: true })
        ]));
});

Вывод будет выглядеть так:

Окно терминала с результатами задачи stylelint Gulp
Окно терминала с результатами задачи stylelint Gulp (Просмотреть большую версию)

Чтобы использовать таблицу стилей, отличную от CSS, вам необходимо установить соответствующий синтаксис. Например, для проверки SCSS нам нужно установить postcss-scss:

npm install postcss-scss --savedev

Затем настройте gulp-postcss использовать этот синтаксис:

var postcss = require('gulp-postcss');
var reporter = require('postcss-reporter');
var stylelint = require('stylelint');
var scss = require("postcss-scss");

gulp.task('lint:css', function() {
    return gulp.src('src/**/*.scss')
        .pipe(postcss(
            [
                stylelint({ /* options */ }),
                reporter({ clearMessages: true })
            ],
            {
                syntax: scss
            }
        ));
});

Вы можете явно указать файл конфигурации; иначе stylelint будет искать .stylelintrc.

Вывод

Stylelint — мощный линтер таблиц стилей. Это вносит ясность в код и избавляет вас от ошибок. Это полезно для всех: отдельных разработчиков, команд и специалистов по сопровождению открытого исходного кода. Как только вы начнете использовать его, вы больше не услышите комментариев типа «Вы забыли добавить пробел здесь» или «Вы забыли убрать его там». Удачной разработки, и пусть у вас будет мирный обзор кода.

Сокрушительная редакция
(рб, мл, ал, ил)




Source: https://smashingmagazine.com

Заключение

Вы ознакомились с статьей — Stylelint: линтер таблицы стилей, которого мы всегда хотели

Пожалуйста оцените статью, и напишите комментарий.

Похожие статьи

Добавить комментарий

Ваш адрес email не будет опубликован.

Краткое описание по статье Stylelint: линтер таблицы стилей, которого мы всегда хотели

Название: Stylelint: линтер таблицы стилей, которого мы всегда хотели . Краткое описание: ⭐ Алекс Худо . Дата публикации: 04.02.2022 . Автор: Алишер Валеев .

Для чего создан сайт Novosti-Nedeli.ru

Данный сайт посвящен новостям мира и мира технологий . Также тут вы найдете руководства по различным девайсам.

Сколько лет сайту?

Возраст составляет 3 года

Кнопка «Наверх»