W3C валидация css написанного scss — какие есть оффлайн инструменты для проверки?

Question

[bormor]

Ситуация:
Есть проект с SCSS и сборкой на Gulp. Верстальщики используют Sublime и VSCode.
Ищем удобные инструменты проверки валидности css.

Идеальный вариант:
- линтер в ide верстальщика, который прямо в SCSS файле показывает ошибки в CSS.
- плюс npm модуль, который можно повесить на precommit (с поддержкой sourcemap - чтоб показывал ошибки прямо в scss файле)

Какие вообще есть варианты решений?
Пока нашли только scss-lint, но вроде проверяет только ошибки комплияции SCSS и codestyle.
Тоже хорошо, но мало - можно написать нерабочий код css который проходит проверку.

Answer 1

[Demian Smith]

Вот пожалуй лучший линтер https://www.npmjs.com/package/stylelint

Прогонять CSS через валидатор W3C - это очень плохая аматорская идея, не дающая абсолютно никаких выигрышей и невероятно изматывающая разработчиков. Вместо того чтоб писать чистый, пригодный, модульный ЦСС, разработчики начинают изворачиваться дабы ублажить валидатор. Линтера и здравого смысла обычно хватает.

Лучший валидатор - это браузер.

UPD

Очень хороший способ держать цсс в вменяемом состоянии: ставите husky ( https://github.com/typicode/husky ) - это утилита, которая добавляет гитхуки. Затем в package.json в секцию scripts добавляет команду precommit, которая будет вызвать stylelint. Каждый раз, когда девелопер коммитит, будет вызываться гитхук и проверять SCSS. Если в нём обнаружились проблемы, то линтер о них сообщит и коммит не пройдёт. Вроде как WebStorm и другие популярные IDE понимают файл .stylelintrc, в котором будут описаны ваши правила валидации.

UPD UPD
Чёрт возьми, Тостер - ресурс для программистов, не поддерживает makrdown и не может распарсить URL. Это просто позор.

Comments

[bormor]

Да, похоже это оптимально решение. Что приятно - работает с sass, scss, less, css.
Протестируем и отпишусь. Может найтем еще какие интересные варианты его использования.

[bormor]

Demian Smith, Отличная штука, почти то что нужно.

Правда запуск по npm run test около 10 секунд - это нормальное явление?
(в тестовом проекте с 1 scss файлом на 3 строки, даже если все тесты ок)

// package.json
  "scripts": {
    "test": "stylelint \"app-src/scss/**/*.scss\" && exit 0"
  },

скрин замера

Верстальщики привыкли, что коммиты делаются мгновенно, а поставив на precommit эта задержка будет всех слегка сбивать с привычного рабочего процесса. Будут сопротивлятся.

[Demian Smith]

bormor, может у вас старый комп? на маке с ссд на небольшом проекте эта команда отрабатывает практически мгновенно. Может слегка запнуться если в файле есть ошибки. Но на самом деле, даже 3 секунды - это мелочь. Верстаки будут ныть полдня максимум, а потом привыкнут.

Для того чтоб не мучать линтерами других разработчиков, не связанных с scss или не всегда коммитящих scss - ставят вот такую штуку https://github.com/okonet/lint-staged . В этом случае линтер срабатывает только на те scss файлы, которые будут закоммичены. На проектах, где и бэкенд и фронтенд в одной репе, бэкендеры могут даже и не знать о существовании линтеров-шмитреров. Но узнают о них сразу же как только пытаются воткнуть портак.

Вот пример, как это всё связать, выдранный из рабочего проекта

{
  "scripts": {
    "precommit": "lint-staged"
  },
  "lint-staged": {
    "linters": {
      "app-src/**/*.{scss,css,sass}": [
        "stylelint"
      ]
    }
  },
  "devDependencies": {
    "husky": "^0.14.3",
    "lint-staged": "^4.0.4",
    "stylelint": "^8.1.1"
  }
}

если воссоздать такую структуру у себя в package.json, то достаточно сделать npm install и всё заработает.

Наслаждайтесь! ;-)

Ах да, `&& exit 0` можно не писать в скриптах.

[Demian Smith]

Demian Smith, есть еще такой вариант что у вас нод староват, поэтому медленно работает.

[bormor]

Спасибо за подсказки.
По скорости - нода последняя, скорее всего это от железа.

Answer 2

[Егор Живагин]

scss-lint должен подойти, вам как раз и нужен codestyle

Что вы имеете ввиду под "нерабочий код css" ? Ошибки валидации css по W3C - штука очень спорная

Comments

[Demian Smith]

К сожалению scss-lintу нужен ruby, что делает его недостаточно удобным. Мы ведь клёвые разработчики и хотим чтоб весь фронтенд разворачивался по npm install без дополнительных плясок с ruby gem install.

[bormor]

Егор Живагин, "нерабочий" в смысле вроде можно написать не существующее имя css правила, scss скомпилируется корректно, а css работать не будет. Аналогично при опечатках в css правилах.