Хабрахабр

10 PostCSS плагинов, которые сэкономят время вашему верстальщику

Изменяют его. У нас, у фронтендеров, есть такая категория инструментов, которые никак не решают стоящие перед нами задачи, а скорее влияют на сам процесс их решения. Но, так или иначе, сегодня мы поговорим про PostCSS — один из таких инструментов. Отношение к таким инструментам самое разное – начиная от мании в духе “давайте эту штуку пихать везде, это же так круто” и заканчивая отговорками вроде “раз не решает задачи бизнеса, значит оно нам не нужно”.

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

PostCSS vs SASS

Думаю сейчас редкий верстальщик не встречался с препроцессорами. Ох… Видимо стоит сказать пару слов про это. Кто-то пытается выжимать из них максимум, кто-то использует минималистичный набор – вложенность, переменные, импорты. SASS или любимый мною LESS, реже Stylus, применяют и на больших проектах, и на маленьких. Они делают так, чтобы нам было удобнее писать код. Но, так или иначе, эти инструменты помогают с вопросами синтаксиса.

И это понятно. Года два-три назад PostCSS постоянно сравнивали с препроцессорами. Но все это вызывало бурления в массах, в основном потому, что каждый с помощью PostCSS делал что-то свое. Формально с его помощью можно сделать все то же самое, сделать какой-то синтаксис, который будет удобнее, чем чистый CSS. Это как Vim или Emacs – можно из них сделать космический корабль, но научить другого разработчика им пользоваться будет очень непросто. Бесчисленные неизвестные плагины, миллионы комбинаций и кроме автора того или иного конфига никто не понимал, как он работает и что делает.

Никто не мешает использовать SASS ради синтаксиса, а после сборки воткнуть PostCSS и что-то сделать с результатом. Но если эти сравнения отбросить, то PostCSS – это инструмент, который позволяет взять наш CSS и что-то с ним сделать. Они друг другу не противоречат.

Старое – не значит неработающее

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

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

Но вы всегда можете добавить что-то в комментариях. Но приступим… Я собрал десяток плагинов, которые на практике показали свою способность упрощать жизнь верстальщикам и экономить время при разработке.

№1. Doiuse

https://github.com/anandthakker/doiuse

Проверяешь в FF – ок. Думаю все мы сталкивались с такой проблемой: пишешь код, проверяешь в хроме – все ок. Или в Edge. А потом в мобильном Safari все разваливается. Потом долго пялишься в код, пьешь чай, и вдруг приходит озарение, что какое-то свойство не поддерживается в каком-то браузере. И ты сидишь и не понимаешь, что не так. Идешь на caniuse и видишь подтвержение очевидного.

Можно не выспаться, могут быть сжатые сроки и нервы, может поменяться список браузеров, которые нужно поддерживать. Конечно, с опытом руки сами запоминают, какие свойства нужно избегать, но всякое бывает. Doiuse – это инструмент, который очень выручает в таких ситуациях. И тут опыт начнет подводить.

Плагин идет в базу caniuse и в реальном времени выдает нам ответ, что мы поиспользовали из того, что не поддерживается. Принцип работы прост – мы скармливаем ему список браузеров и наш CSS.

Просто и удобно. Список браузеров мы можем задавать прямо в package.json. PostCSS использует browserslist и, если вы не видели раньше, то выглядит это примерно так:

"browserslist": [ "> .5% and last 2 versions", "not dead", "not OperaMini all", "ie >= 11", "Edge >= 12"
]

Например если вы используете полифилы или от потери поддержки какого-то свойства ничего не изменится: Также есть конфиг самого doiuse, в котором можно заставить его игнорировать некоторые группы свойств, если вы уверены, что это ни на что не влияет.

ignore: [ 'will-change', 'object-fit'
]

Он содержит много информации и воспринимать его не очень удобно. Стандартный лог, который дает плагин, не очень читаемый. В том же конфиге мы можем сделать свою функцию для формирования лога. Но это дело поправимое.

Там много всего интересного. Используйте console.log чтобы сообразить, как устроен объект, который передает PostCSS в эту функцию.

Если в проекте используется БЭМ или какие-то аналоги, и код компонентов распределен по отдельным файлам, то такой подход позволяет быстро находить проблемное место не нагружая мозг. Моя практика показала, что самый удобный вариант – это выводить селекторы и конкрентые свойства, которые не поддерживаются, без уточнения браузеров и строк кода.

onFeatureUsage(info) : ${info.usage.value}`; let status = info.featureData.caniuseData.status.toUpperCase(); if (info.featureData.missing) { status = 'NOT SUPPORTED'.red; } else if (info.featureData.partial) { status = 'PARTIAL SUPPORT'.yellow; } console.log(`\n${status}:\n\n ${selector} {\n ${property};\n }\n`);
}

Чтобы не писать специальные последовательности символов для цветов в консоли, можно подключить пакет colors, с ним будет удобнее.

При сборке будет примерно такой вывод в консоли:

NOT SUPPORTED: html { -ms-text-size-adjust: 100%; } NOT SUPPORTED: html { -webkit-text-size-adjust: 100%; } PARTIAL SUPPORT: body { display: flex; }

№2. Autoprefixer

https://github.com/postcss/autoprefixer

Такие действия приводят к тому, что код зарастает кучей ненужных префиксов и становится совершенно нечитаемым. Даже как-то неловко про него говорить, но уж слишком часто вижу людей, которые в 2019 году пишут префиксы руками и еще уверяют окружающих, что они точно знают, какие из них нужны, а какие – нет. С другой стороны, если нужна поддержка динозавров, то всегда можно что-то забыть. Это влияет на производительность труда. Так что от ручного труда при решении этой задачи стоит избавляться.

При этом сам код становится чище, а работа идет быстрее. Автопрефиксер работает все с той же базой caniuse, использует тот же browserslist и может добавлять в CSS те префиксы, которые действительно нужны в указанных нами браузерах.

№3. Stylelint

https://github.com/stylelint/stylelint

Глаз замыливается. Когда много и быстро печатаешь, то рано или поздно начинаешь допускать много ошибок, совершенно их не замечая. Смотришь в код – ее там нет. В случае с CSS это может давать забавный (на самом деле нет) эффект, когда ты смотришь в браузер – видишь проблему с версткой. А в коде – нет. Смотришь в браузер – она есть. Чтобы такого не было, придумали линтеры. В результате можно долго искать сложную проблему, совершенно не замечая, что просто очепятался.

Он умеет работать с синтаксисами основных препроцессоров, знает о последних веяниях в CSS, можно настраивать на свой вкус – конфиги похожи на те, что у eslint. Stylelint – это популярный вариант. Формально этот инструмент можно использовать и сам по себе, без PostCSS, но не упомянуть его здесь было бы неправильно.

№4. Postcss-flexbugs-fixes

https://github.com/luisrudge/postcss-flexbugs-fixes

Медленно, но верно, флексы вытесняют старый подход к верстке на флоатах. Или в более широком смысле postcss-fixes, в состав которого этот плагин входит. Они описаны в репозитории flexbugs. Это хорошо, но все мы знаем, что с ними связан набор багов. Например IE игнорирует функцию calc в сокращенной записи свойства flex. Некоторые из них требуют к себе особого внимания, но также есть несколько штук, которые настолько простые, что постоянно вылетают из головы. К счастью это дело можно исправить в автоматическом режиме. Это не так часто нужно, но если понадобится, то руки могут сами написать сокращенный вариант и потом придется долго думать, в чем проблема. На помощь приходит плагин postcss-flexbugs-fixes.

В примере с calc он найдет в коде фрагменты вроде этого:

.foo { flex: 1 0 calc(1vw – 1px);
}

И развернет их:

.foo { flex-grow: 1; flex-shrink: 0; flex-basis: calc(1vw - 1px);
}

Просто и удобно.

№5. Postcss-preset-env

https://github.com/csstools/postcss-preset-env

Раньше ту же роль выполнял cssnext. Раз уж мы говорим про поддержку браузерами, то будет не лишним сказать про postcss-preset-env. Этот плагин будет полезен, если вы интересуетесь новыми веяниями в CSS.

Preset-env помогает писать код по-новому, экономить на этом время, а потом преобразовывать его в старый надежный вариант. Многие из нововведений технически можно реализовать и старыми методами, просто это будет долго, многословно и некрасиво. Разумеется, некоторые вещи вроде кастомных свойств совсем не реализованы в старых браузерах, так что там будут применяться фолбеки.

Здесь все так же – много преобразователей, собранных в один стабильный набор. Как можно догадаться по названию инструмента, он напоминает одноименный пресет у Babel. Насколько я понимаю, для Stage2+ скрипты не нужны. Некоторые преобразования требуют последующее подключение скриптов-полифилов на клиенте, но большинство реализуется чисто средствами CSS. Поправьте меня, если я что-то там пропустил. Во всяком случае не сталкивался с их необходимостью.

№6. Postcss-animation

https://github.com/zhouwenbin/postcss-animation

Вполне логично. Часто слышу от разных людей (в основном это бэкендеры, которые не очень сильны в CSS), что они хотят использовать отдельные анимации из animate.css, но считают плохой идеей подключать всю библиотеку целиком. Но в результате они тратят много времени пытаясь повторить эти анимации самостоятельно.

Мы пишем только название анимации, например: Плагин postcss-animation очень ускоряет этот процесс.

.foo { animation-name: bounce;
}

А он сам подтягивает из animate.css реализацию и вставляет ее в код.

.foo { animation-name: bounce;
} @keyframes bounce { from, 20%, 53%, 80%, to { animation-timing-function: cubic-bezier(0.215, 0.610, 0.355, 1.000); transform: translate3d(0,0,0); } 40%, 43% { animation-timing-function: cubic-bezier(0.755, 0.050, 0.855, 0.060); transform: translate3d(0, -30px, 0); } 70% { animation-timing-function: cubic-bezier(0.755, 0.050, 0.855, 0.060); transform: translate3d(0, -15px, 0); } 90% { transform: translate3d(0,-4px,0); }
}

№7. List-selectors

https://github.com/davidtheclark/list-selectors

Знать, какие ID используются, есть ли селекторы по тегам или насколько соблюдается принятая методология. Когда у вас есть несколько верстальщиков и много стилей, встает вопрос о code review, о том, что было бы неплохо иногда глазами видеть общую картину со всеми селекторами, которые у нас есть. Самому пролистывать многочисленные файлы со стилями, чтобы проверить адекватность селекторов, долго. Особенно это важно, когда вы проверяете код новичка, который может писать странные вещи, которые формально будут работать, но фактически будут идти вразрез с принятыми соглашениями (далеко не везде эти соглашения хорошо зафиксированы и есть возможность такие вещи автоматизировать). List-selectors как раз решает эту задачу. Нужен способ вычленить их и показать отдельно.

Можно вывести только то, что интересует, или раскрасить все в разные цвета. Точно так же, как и doiuse, этот плагин позволяет использовать свою функцию для подготовки информации к выводу на экран. Как пример:

require('list-selectors').plugin((list) => { const inspect = require('util').inspect; console.log('SELECTORS:'.blue); console.log(inspect(list.selectors, { maxArrayLength: null }).blue); console.log('IDS:'.red); console.log(inspect(list.simpleSelectors.ids, { maxArrayLength: null }).red);
})

В этом примере получится длинный-длинный список селекторов:

SELECTORS:
[ '.mui-progress-bar', '.mui-progress-bar > .indicator', '.mui-progress-bar > .value', '.mui-progress-bar.-radial', '.mui-progress-bar.-radial > .indicator', '.mui-progress-bar.-radial > .indicator > .background', '.mui-progress-bar.-radial > .indicator > .progress', '.mui-progress-bar.-radial > .value', . . .

№8. Immutable-CSS

https://github.com/johno/immutable-css

Если мы подключили какую-то библиотеку, а потом начинаем для селекторов из нее писать свои стили, то в конечном счете получаем запутанный код, в котором не разобрать, что откуда взялось. Еще одна вещь, за которой стоит следить – это перебивание стилей из сторонних библиотек. Чем больше раз мы что-то переопределяем, тем сложнее в конечном счете понять, что происходит, хотя сама проблема, которую нужно решить, может быть очень простой. Это может приводить к случайным багам, которые потом отнимают слишком много времени на ровном месте. В этой ситуации может пригодиться инструмент под названием immutable-css.

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

! .button was mutated 2 times
[line 93, col 1]: /css/basscss.css
[line 3, col 1]: /css/custom.css
[immutable-css]
! .left was mutated 2 times
[line 291, col 1]: /css/basscss.css
[line 4, col 1]: /css/custom.css
[immutable-css]

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

№9. Bye-Bye!

https://github.com/AoDev/css-byebye

Какие-то из них отправляются сразу в продакшен, а какие-то долго сидят и ждут своей очереди (например сверстать-то мы сверстали, а не бэкенде еще что-то не доделали). Думаю всем знакома ситуация, когда мы постепенно добавляем какие-то компоненты на работающий сайт. Ситуаций может быть много, но их объединяет то, что у нас набирается куча компонентов, а на боевом сайте используются лишь малая часть из них. Что-то может быть экспериментом или временным решением на праздники. Это может заметно уменьшить ее размер, а также снизить головную боль в перспективе, когда нужно будет делать редизайн к примеру, и встанет вопрос, что же из всего этого действительно нужно переписывать сейчас, а что — нет. Было бы хорошо убрать все, что не используется, из текущей сборки.

На ум сразу приходит uncss. Есть разные подходы к этому вопросу. Но на практике это почти всегда приводит к тому, что никто не знает, что реально используется, а что – нет. Этот инструмент в автоматическом режиме определяет, какие стили используются на страницах и убирает лишнее. Но это наверное уже моя паранойя. А еще я все время сомневаюсь, не удалил ли этот инструмент чего лишнего. Хотя...

Причем можно использовать регулярные выражения. Bye-bye – это более простой инструмент, которому мы сами скармливаем список селекторов, которые нужно убрать из CSS. Bye-bye! Если вы применяете БЭМ или что-то еще в этом духе, то одной простой регуляркой можно удалять блок со всем, что к нему относится.

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

№10. PostCSS-trolling

https://github.com/juanfran/postcss-trolling

Очень рекомендую. Все предыдущие инструменты могут незначительно повысить производительность труда ваших верстальщиков, но этот дает просто феноменальные результаты.

Заключение

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

Теги
Показать больше

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

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

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть