Как бы удивительно это ни звучало, написание рабочего кода на самом деле является легкой частью при разработке веб-сайта, приложения или любого программного обеспечения. Сделать все это масштабируемым, протестированным, должным образом документированным и легким для внесения вклада — сложная задача.
Одна часть имеет кодовую базу, которая является чистой и последовательной. Чистота, потому что поддерживать уродливый «странный» код определенно не приятно и непротиворечиво, потому что это делает обслуживание базы кода проще и быстрее. Если код везде выглядит одинаково в программном обеспечении, то должно быть достаточно быстро привыкнуть к тому, как он написан.
Когда дело доходит до Sass, есть несколько вещей, которые вы можете сделать, чтобы сделать ваш код чистым и последовательным. Первым из них будет соблюдение некоторых правил кодирования, таких как CSS CSS Guidelines и Sass Guidelines . Другое дело — привязать вашу кодовую базу.
Если вы не знакомы со словом lint , вот что говорит Википедия:
В компьютерном программировании lint было именем, изначально присвоенным конкретной программе, которая помечала некоторые подозрительные и непереносимые конструкции (вероятно, ошибки) в исходном коде языка Си. Этот термин теперь применяется в общем для инструментов, которые отмечают подозрительное использование в программном обеспечении, написанном на любом компьютерном языке.
Что было бы подозрительным использованием в Sass? Это зависит от того, как вы определяете подозрительные, но, в более широком смысле, это может быть просто вопросом обеспечения того, чтобы таблица стилей оставалась легко читаемой и не сложной. Например, можно ограничить использование вложенности селектора одним уровнем.
Чтобы связать нашу базу кода Sass, существует один адский инструмент под названием SCSS-lint . Теперь давайте начнем с плохих новостей: SCSS-lint является гемом Ruby, и независимо от того, как вы его используете (CLI, Grunt, Gulp…), вам нужно будет установить этот гем заранее. С другой стороны, некоторые замечательные люди в настоящее время разрабатывают порт SCSS-lint в виде пакета npm, поэтому мы могли бы рано или поздно избавиться от этого утомительного дополнительного шага. Правильно. Давайте покончим с этим:
$ gem install scss_lint Примечание: гем называется scss_lint по причине именования, но инструмент командной строки на самом деле является scss-lint . И библиотека называется SCSS-lint. Потому что это не было достаточно сложно … ?
Начало работы с инструментом CLI
SCSS-lint поставляется с большим количеством опций. На самом деле, так много, что поначалу это может показаться немного ошеломляющим. К счастью, на самом деле не так много тех, которые мы будем часто использовать, поэтому давайте посмотрим на них.
С помощью параметра -c или --config вы можете передать путь к файлу конфигурации, который будет полезен для определения правил, которые вы хотите применить к своей базе кода. Например:
$ scss-lint . --config .scss-lint.yml
В зависимости от вашего проекта вы можете использовать опцию -e или --exclude чтобы исключить некоторые файлы или папки из процесса линтинга. Например, вы можете не захотеть линтовать свои сторонние библиотеки или модули вашего узла. Например
$ scss-lint . --exclude ./node_modules/**/*
Для более сложного использования --exclude вы можете определить его в файле конфигурации, передаваемом через --config .
Есть и другие варианты, но я чувствую, что этого более чем достаточно, чтобы начать.
Первый аргумент, передаваемый scss-lint — это папка для запуска. Если опущено, по умолчанию . текущая папка. Если вы хотите указать конкретную папку, вы можете:
scss-lint ./assets/stylesheets
Настройка линтеров
Теперь, когда мы готовы использовать нашу базу кода Sass, нам нужно определить, к каким правилам мы должны придерживаться. SCSS-lint имеет так много линтеров , как они называются, настолько, что перечислять их все здесь будет слишком долго. Я рекомендую вам ознакомиться с документацией линтеров .
Идея состоит в том, что вы создаете YAML-файл в корне вашего проекта, содержащий всю вашу конфигурацию линтинга. По умолчанию SCSS-lint будет пытаться .scss-lint.yml файл .scss-lint.yml в текущей папке, поэтому я рекомендую вам назвать этот файл следующим образом. Однако, если вы предпочитаете другое имя, вы можете; обязательно передайте его с параметром --config , вот и все.
У Sass Guidelines есть файл конфигурации, готовый для вас, чтобы вы могли его взять и использовать в своем проекте. Обязательно посмотрите более подробно, если вы хотите настроить вещи, но в целом это должно сработать.
Linting при совершении
Единственное, что нужно сделать, — это убедиться, что код чист ( помечен ) при фиксации с помощью ловушки предварительной фиксации. Я немного поиграл с тестированием Sass и ловушками перед фиксацией в предыдущей статье здесь, на SitePoint, под названием « Тестирование библиотеки Sass» .
Если вы не уверены, что такое ловушка перед фиксацией, в основном это механизм, направленный на выполнение некоторых операций перед применением фиксации. Если какая-либо из выполненных операций вызывает ошибку, то фиксация прерывается.
Убедиться, что код написан перед фиксацией в удаленном репозитории, — это идеальный вариант использования Git-хука. В этом разделе мы увидим, как мы можем установить это очень простым способом.
Для этого мы будем использовать очень легкий пакет npm, обеспечивающий поддержку перехватчиков Git в направлении файла package.json . Для этого есть много библиотек, но я лично выбрал предварительную фиксацию . Вот как это выглядит:
{ "scripts": { "lint": "scss-lint ." }, "pre-commit": [ "lint" ] }
При фиксации ловушка предварительной фиксации запускается и запускает скрипт lint npm (точно так же, как npm run lint ). Скрипт lint npm, как видно из кода, запускает scss-lint . команда. Если SCSS-lint возвращает ошибку, фиксация прерывается, и код должен быть исправлен для прохождения фиксации.
Если вы запускаете SCSS-lint через Gulp, Grunt или что-то еще, вы можете запустить задачу в сценарии lint npm вместо непосредственного использования scss-lint . В том же ключе вы можете передать такие параметры, как --config или --exclude .
Последние мысли
Мы всегда можем пойти дальше, но я думаю, что это хорошее введение в SCSS-lint, и мы действительно можем использовать его в существующих и новых проектах простым, но мощным способом.
Нет причин продолжать комить грязный код, ребята, перед тем как нажать его,