post css что это
PostCSS
A tool for transforming CSS with JavaScript
Increase code readability
Add vendor prefixes to CSS rules using values from Can I Use. Autoprefixer will use the data based on current browser popularity and property support to apply prefixes for you.
Use tomorrow’s CSS today!
PostCSS Preset Env, lets you convert modern CSS into something most browsers can understand, determining the polyfills you need based on your targeted browsers or runtime environments, using cssdb.
The end of global CSS
CSS Modules means you never need to worry about your names being too generic, just use whatever makes the most sense.
Avoid errors in your CSS
Enforce consistent conventions and avoid errors in your stylesheets with stylelint, a modern CSS linter. It supports the latest CSS syntax, as well as CSS-like syntaxes, such as SCSS.
Is your company using PostCSS? Join this list!
Trusted by industry leaders
Built by community for community
PostCSS is developed and maintained by hundreds of open source contributors. Become part of the family — submit your first Pull Request!
PostCss, полное погружение: Все, что Вам нужно знать
Russian (Pусский) translation by Dimkin (you can also view the original English article)
Если Вам, на самом деле нужно узнать что-то о PostCss, то давайте скорее приступим и узнаем, как его можно использовать.
В этой серии уроков, мы постараемся погрузиться максимально глубже и узнать основные пути, как мы можем использовать PostCss. Если вы еще не поняли, на что способен PostСss, то будьте готовы к новому и прекрасному миру CSS.
Вступление
Как Вы видите на графике, популярность PostСss, растет с головокружительной скоростью. Все больше людей начинает понимать, что предлагает PostСss, наслаждаясь «моментом просветления», они понимают, как они могут использовать его в своих проектах.
В 2014 г. насчитывалось, чуть больше 1..4млн загрузок за год, но начиная с Января по Июнь 2015 года, уже было больше 3.8млн загрузок.
Autoprefixer, весьма популярный плагин PostCSS, он использвался в Google, Shopify, Twitter, Bootstrap и CodePen. WordPress, также использует Autoprefixer, а также RTLCSSplugin. Также Alibaba использует несколько PostCSS плагинов, для собственных разработок, а также для содействует для разработки других проектов.
Помимо этого, Марк Отто, говорил, что в 5ой версии Bootstrap, будет написан на PostCss.
Кстати, Bootstrap 4, будет на SCSS. Bootstrap5, будет на PostCss звучит заманчиво!
PostCss, уже встроен в виртуальную среду для тестов Codepen.io и может быть использован, нужно только изменить соответсвующие настройки.
PostCSS on CodePen
Одним словом, PostCss растет быстро, и на это есть хорошие причины.
PostCss в двух словах
Так что же такое PostCss? Лучше описание, которое приходит с проекта на ГитХабе:
PostCss, это инструмент, для изменения Css с помощью Яваскрипт. Различные плагины, могут поддерживать переменные и миксины, транслировать новый синтаксис «css 4», встроенные картинки и многое многое другое, на что способен PostCss.
В двух словах, PostCss берет CSS и превращает в вид данных, которые можно изменять с помощью Яваскрипт. Основанные на Яваскрипт плагины, позволяют изменять код. PostCss сам по себе ничего не изменяет, он всего лишь прокладывает путь для плагинов, которые делают изменения и траснформации для которого они созданы.
Практически не существует ограничений в манипуляции плагинами для PostCss, которые можно применить к CSS. Если вы можете подумать о чем либо, то это можно сделать с помощью плагинов для PostCss.
Плагины PostCss, могут вести себя как препроцессоры: могут оптимизировать и добавлять префиксы в код, могут добавлять синтаксис из будущих спецификаций, могут выполнять проверку, могут производить переменные и логику, можно создавать сетки. этот список очень длинный и разнообразный.
Чем не является PostCss
Тот факт, что вы можете делать все что угодни с PostCss плагинами, в сочетании с тем, что PostCss является относительном «свежим созданием», приводят к заблуждению и недопониманию, что он из себя представляет на самом деле.
Многие люди,(включая меня), имели не полное представление о том, что такое PostCss, и поэтому я упустил, истинное предназначение этого инструмента.
Поэтому, прежде, чем мы пойдем дальше, давай проясним, чем не является PostCss.
PostCss это не препроцессор.
Много разработчиков, сказали, что отказываются от препроцессоров в пользу PostCss. В то же время, другие отдают свои предпочтения препроцессорам и им не нравится PostCss. Однако PostCss не препроцессор.
Да, вы конечно же можете его использовать в качестве препроцессора, но вы также можете использовать его функции, не как препроцессора. Вы даже можете использовать свой любимый препроцессор в соединении с PostCss.
PostCss имеет в своем составе слово пост, но на самом деле это не пост-обработка. Пост-обработка, обычно рассматривается как «приемка» готовых стилей, таких как валидный css синтаксис и обработка с добавлением вендорных префиксов. Тем не менее, PostCss не ограничивается только обработкой или как это кажется на первый взгляд. Как упоминалось раннее, он может вести себя также, как и препроцессор.
Это лучшее, что можно подумать о PostCss. like препроцессор. Как сказал Андрей Ситник в своем твиттере, создатель PostCss:
Настало время признать свои ошибки. Термин «препроцессор», было плохой идеей. Команда PostCss перестала использовать это значение. https://t.co/vs2AiXGoJy
А также, внесший большой вклад в разработку плагинов, Максим Тируин, описал в своем твиттере: PostCss, чаще подразумевает не пост обработку, а как смысл самого CSS или даже больше, чем смысл.
PostCss это не синтаксис будущего.
Существует несколько прекрасных плагинов PostCss, которые позволяют писать код из будущих спецификаций, но пока, мало кто пользуется этими возможностями. Однако, сам по себе PostCss, не поддерживает синтаксис будущего.
Некоторые разработчики, неохотно используют PostCss, объясняя это тем, что они не чувствуют себя комфортно при написании «синтаксиса будущего». Однако, написание «синтаксиса будущего», это только один из множества путей, как можно использовать PostCss.
Если вы хотите, то вы можете использовать PostCss, который перевернет ваше представления о процессе разработки, даже без написания одной строчки кода.
Успех плагина Autoprefixer, привело к тому, что PostCss стали воспринимать как оптимизатор и «чистильщик» кода, который ускоряет скорость разработки и и добавляет кросс-браузерность(префиксы) по умолчанию. Такое ошибочное понимание, было и у меня, пока я не научился огромному количеству других вещей, которые дает PostCss.
Да, существует много замечательных плагинов, которые предлагают чистку кода и оптизацию процесса, но это всего лишь малая толика из того, что он предлагает.
Важно знать, что PostCss на зацикливается на какой то одной операции, он представляет целый комплекс кастомных решений, функционалность которых практически не имеет предела.
Рассмотрим например плагин для Вордпресс. Е-commerce плагины очень популярны, но никто не считает двидок Вордпресс как часть коммерции, и также заслуга самого Вордпресс, не оценена в разработки е-коммерции.
В случае с PostCss, мне нравится думать о нем, как о хлебе, т.е. это всего лишь ингридент, из которого вы можете приготовить вкусный сэндвич. Сам по себе PostCss, не кажется чем то сверхественным, но то, что он способен(с помощью плагинов), позволяет заполнить практически все аспекты разработки. Это дает бесконечные возможности, которые просто могут создавать что то удивительное.
Сэндвич вчера.
Попробовал сэндвич с арахисовым маслом м не понравилось? Это не повод, обвинять хлеб, что все сэндвичи будут ужасны. Вместо этого, давайте перейдем к следующем удивительным вещам, которые могут стать частью вашей обычной жизни.
Что делает PostCss особенным.
Давай посмотрим, на несколько вещей, что делает PostCss особенным.
Его экоситема плагинов, предлагает различную функциональность.
Вот некоторые из них, которые позволяют применять цветовые решения, конические градиенты, кастомные свойства, кастомные селекторы, кастомные имена для медиазапросов и многое многое другое.
На данный момент, существует несколько фоллбэк плагины, которые позволяют использовать современный код, для устаревших браузеров, например использование относительных единиц, rgba() цветов, конвертирование псевдоэлементов.
Также доступны более 20 языков расширений, включая миксины, переменные, условия для каждой «петли», также включены стили БЭМ и SUIT и многие другие.
Плагин по работе с цветами, позволяет конвертировать из одного цветового формата в другой, также можно изменять альфа насыщенность, комбинировать цвета, генерировать цветовые схемы.
Также есть плагины для создания любых сеток, оптимизатор, плагин который создает необходимые шорткаты, линтеры и другие аналитические инструменты.
Невозможно вместить в один параграф, многообразие существующих плагинов и их растущее количество, по ссылке, вы можете просмотреть весь список.
Он модульный: т.е. используйте только то, в чем вы нуждаетесь.
Другая сторона PostCss, то что вы можете использовать все их одновременно или какие то определенные, подходящие под вашу задачи.
Просто хотите использовать PostCss, чтобы сделать ваш css более эффективным и кросс-браузерным? Загрузите несколько плагинов для оптимизации и вперед!
Хотите использовать PostCss как препроцессор? Просто используйте некоторые плагины вместо использования языка и все готово.
Например, вы можете вручную собрать набор плагинов в образ и создать свой собственный препроцессор. Или как альтернативы, вы можете скачать PreCss плагин, который вам автоматом даст доступ, к нескольком плагинам.
Какой бы вы путь ни выбрали используя PostCss, вы можете выбрать только нужные вам плагины из набора, не устанавливая остальной не нужный хлам.
PostCss быстрее в 3 раза, чем остальные известные «препроцессоры.»
Вы можете попробовать эти тесты сами пройдя по ссылке ниже: https://github.com/postcss/benchmark
Результат одного из тестов, это парсинг, вложеные правила, миксины, переменные и math:
Вы также можете создать свой собственный плагин, на любой случай
Плагины для PostCss, написаны на яваскрипт, и любой кто умеет писать на этом языке, может создать свой собственный плагин, для своих нужд. Чтобы дать вам представление как это возможно, я например, не считаю себя крутым яваскрипт разработчиком, но после подробного анализа PostCss, я за несколько часов написал свой первый плагин.
Препроцессоры, такие как SASS, Stylus и Less, делают достаточно хорошо свою работу, но они не могут делать все. Они решают за пользователя, какие функции им могут быть полезны. Если вам нужна какая то новая функция, то вы конечно можете сделать запрос, как оно и делается в принципе, но это требует времени и не всегда разработчики могут воплотить в реальность ту или ину запрашиваемую вами функцию, все зависит от спроса.
Даже если вы сделаете запрос на какую то функцию, то не факт, что волонтеры любители, будут иметь время для создания нужной вам фичи. Одним словом, если вы не обладаете мастерством создания нужного функционала, то я скажу вам, что вы неудачник.
С PostCss вы не должны никого спрашивать. Если вам нужна функциональность, вперед и сделайте сами. Из моего опыта знания яваскрипт, позволяет создать PostCss плагин, которым смогут управлять другие разработчики.
В дальнейшем, в одном из уроков, будет показан пример создания собственного плагина. Даже, если вы не эксперт в яваскрипт, то я думаю, вы все равно сможете создать простой плагин, это вполне достижимо.
Вы также можете использовать с обычным css.
Большая часть PostCss, не требует кастомного синтаксиса, что типично для препроцессоров. Скорее, они могут быть применены к обычному css. Это означает, что вы можете использовать PostCss с любым css файлом вместе, например для редактирования стилей или совсем для другого проекта, такого как например NORMALIZE.css
Это также означает и то, что вы не должны «выпадать» из других проектов, таких как SASS, Stylus или Less, потому что, вы всегда можете применить PostCss для обработки css Например, если использовать Foundation через SASS, вы можете выполнить оптимизацию и использовать «будущий синтаксис» после создания вашего css файла.
Библиотеки PostCss не привязаны к одному препроцессору.
Мы также начинаем видеть многие библиотеки написанные на PostCss, которые в прошлом были написаны на Stylus, Sass или LESS.
Например Cory Simmons, изначально занимался поддержкой Stylus и Sass для его Lost Grid системы, так что пользователи имели доступ к его творению. Впоследствии он портировал свой проект на PostCss, что означает, что сейчас каждый может использовать Lost, включая Stylus, Sass пользователей и не только, также пользователи Less и люди которые вообще не использовали препроцессоры.
PostCss быстро интегрируется в популярные инструменты.
Будучи основанным на яваскрипт, PostCss не нуждается в установке Ruby, он имеет уже готовую систему для разработки.
Окей, пройдем к моменту, как мы можем быстро начать использовать PostCss.
Подведем итоги:
Первое, что нужно знать о PostCss, что он стремительно набирает обороты и причем не зря, поэтому сейчас настал момент ясности и понимания, как мы можем использовать этот замечательный инструмент.
В этом вступлении, мы выяснили, чем PostCss не является:
Мы также раскрыли, что делает PostCss особенным:
Скоро «Погружение в PostCss»
В этой серии уроков, мы шаг за шагом, будем изучать PostCss уроки:
Также мы рассмотрим, различные пути, как мы можем использовать PostCss
И наконец, мы будем создавать свой собственный плагин PostCss.
Вы могли заметить, насколько мало существует уроков по использованию фичи в PostCss, называемой cssnext, (которая позволяет использовать «синтаксис будущего») особенно учитывая тот факт, что многие люди, считают его пост-обработкой.
Причина этого отсутствия является, продолжающаюся разработка cssnext, лидирующий проект, который все еще трансформируется и находится на стадии шлифовки. Таким образом, мы будем приглядывать за ним и публиковать свежие уроки по мере их выхода в свет.
Итак, приступим! В следующем уроке, будет вступление, «Быстрый старт» и будет показано как мы можем использовать PostCss. Увидимся здесь!
10 PostCSS плагинов, которые сэкономят время вашему верстальщику
У нас, у фронтендеров, есть такая категория инструментов, которые никак не решают стоящие перед нами задачи, а скорее влияют на сам процесс их решения. Изменяют его. Отношение к таким инструментам самое разное – начиная от мании в духе “давайте эту штуку пихать везде, это же так круто” и заканчивая отговорками вроде “раз не решает задачи бизнеса, значит оно нам не нужно”. Но, так или иначе, сегодня мы поговорим про PostCSS — один из таких инструментов.
Волна хайпа уже давно прошла, в последнее время про PostCSS говорят очень мало. Многие новички даже не знают, что это такое. Думаю самое время посмотреть на этот инструмент с точки зрения практического использования в самых обычных проектах, где люди решают задачи, а не играются с модными технологиями.
PostCSS vs SASS
Ох… Видимо стоит сказать пару слов про это. Думаю сейчас редкий верстальщик не встречался с препроцессорами. SASS или любимый мною LESS, реже Stylus, применяют и на больших проектах, и на маленьких. Кто-то пытается выжимать из них максимум, кто-то использует минималистичный набор – вложенность, переменные, импорты. Но, так или иначе, эти инструменты помогают с вопросами синтаксиса. Они делают так, чтобы нам было удобнее писать код.
Года два-три назад PostCSS постоянно сравнивали с препроцессорами. И это понятно. Формально с его помощью можно сделать все то же самое, сделать какой-то синтаксис, который будет удобнее, чем чистый CSS. Но все это вызывало бурления в массах, в основном потому, что каждый с помощью PostCSS делал что-то свое. Бесчисленные неизвестные плагины, миллионы комбинаций и кроме автора того или иного конфига никто не понимал, как он работает и что делает. Это как Vim или Emacs – можно из них сделать космический корабль, но научить другого разработчика им пользоваться будет очень непросто.
Но если эти сравнения отбросить, то PostCSS – это инструмент, который позволяет взять наш CSS и что-то с ним сделать. Никто не мешает использовать SASS ради синтаксиса, а после сборки воткнуть PostCSS и что-то сделать с результатом. Они друг другу не противоречат.
Старое – не значит неработающее
В последнее время у нас модно создавать комбайны, которые умеют делать все, что только в голову придет, и их разработка никогда не прекращается. А если в репозитории уже пару месяцев нет свежих коммитов, то все – можно считать, что он устарел и пользоваться им теперь – не комильфо. Я утрирую, конечно, но думаю вы и сами замечали, до какого абсурда это иногда доходит.
В мире PostCSS обычно один плагин решает одну задачу. Можно тут увидеть элементы философии Unix. Из этого следует логичный вывод – если плагин уже решает свою задачу, то больше с ним ничего особо делать не нужно. Вы можете встретить плагины, которые годами не обновлялись, но это не значит, что они вдруг перестали решать задачи, для которых были созданы.
Но приступим… Я собрал десяток плагинов, которые на практике показали свою способность упрощать жизнь верстальщикам и экономить время при разработке. Но вы всегда можете добавить что-то в комментариях.
№1. Doiuse
Думаю все мы сталкивались с такой проблемой: пишешь код, проверяешь в хроме – все ок. Проверяешь в FF – ок. А потом в мобильном Safari все разваливается. Или в Edge. И ты сидишь и не понимаешь, что не так. Потом долго пялишься в код, пьешь чай, и вдруг приходит озарение, что какое-то свойство не поддерживается в каком-то браузере. Идешь на caniuse и видишь подтвержение очевидного.
Конечно, с опытом руки сами запоминают, какие свойства нужно избегать, но всякое бывает. Можно не выспаться, могут быть сжатые сроки и нервы, может поменяться список браузеров, которые нужно поддерживать. И тут опыт начнет подводить. Doiuse – это инструмент, который очень выручает в таких ситуациях.
Принцип работы прост – мы скармливаем ему список браузеров и наш CSS. Плагин идет в базу caniuse и в реальном времени выдает нам ответ, что мы поиспользовали из того, что не поддерживается.
Список браузеров мы можем задавать прямо в package.json. Просто и удобно. PostCSS использует browserslist и, если вы не видели раньше, то выглядит это примерно так:
Также есть конфиг самого doiuse, в котором можно заставить его игнорировать некоторые группы свойств, если вы уверены, что это ни на что не влияет. Например если вы используете полифилы или от потери поддержки какого-то свойства ничего не изменится:
Стандартный лог, который дает плагин, не очень читаемый. Он содержит много информации и воспринимать его не очень удобно. Но это дело поправимое. В том же конфиге мы можем сделать свою функцию для формирования лога.
Используйте console.log чтобы сообразить, как устроен объект, который передает PostCSS в эту функцию. Там много всего интересного.
Моя практика показала, что самый удобный вариант – это выводить селекторы и конкрентые свойства, которые не поддерживаются, без уточнения браузеров и строк кода. Если в проекте используется БЭМ или какие-то аналоги, и код компонентов распределен по отдельным файлам, то такой подход позволяет быстро находить проблемное место не нагружая мозг.
Чтобы не писать специальные последовательности символов для цветов в консоли, можно подключить пакет colors, с ним будет удобнее.
При сборке будет примерно такой вывод в консоли:
№2. Autoprefixer
Даже как-то неловко про него говорить, но уж слишком часто вижу людей, которые в 2019 году пишут префиксы руками и еще уверяют окружающих, что они точно знают, какие из них нужны, а какие – нет. Такие действия приводят к тому, что код зарастает кучей ненужных префиксов и становится совершенно нечитаемым. Это влияет на производительность труда. С другой стороны, если нужна поддержка динозавров, то всегда можно что-то забыть. Так что от ручного труда при решении этой задачи стоит избавляться.
Автопрефиксер работает все с той же базой caniuse, использует тот же browserslist и может добавлять в CSS те префиксы, которые действительно нужны в указанных нами браузерах. При этом сам код становится чище, а работа идет быстрее.
№3. Stylelint
Когда много и быстро печатаешь, то рано или поздно начинаешь допускать много ошибок, совершенно их не замечая. Глаз замыливается. В случае с CSS это может давать забавный (на самом деле нет) эффект, когда ты смотришь в браузер – видишь проблему с версткой. Смотришь в код – ее там нет. Смотришь в браузер – она есть. А в коде – нет. В результате можно долго искать сложную проблему, совершенно не замечая, что просто очепятался. Чтобы такого не было, придумали линтеры.
Stylelint – это популярный вариант. Он умеет работать с синтаксисами основных препроцессоров, знает о последних веяниях в CSS, можно настраивать на свой вкус – конфиги похожи на те, что у eslint. Формально этот инструмент можно использовать и сам по себе, без PostCSS, но не упомянуть его здесь было бы неправильно.
№4. Postcss-flexbugs-fixes
Или в более широком смысле postcss-fixes, в состав которого этот плагин входит. Медленно, но верно, флексы вытесняют старый подход к верстке на флоатах. Это хорошо, но все мы знаем, что с ними связан набор багов. Они описаны в репозитории flexbugs. Некоторые из них требуют к себе особого внимания, но также есть несколько штук, которые настолько простые, что постоянно вылетают из головы. Например IE игнорирует функцию calc в сокращенной записи свойства flex. Это не так часто нужно, но если понадобится, то руки могут сами написать сокращенный вариант и потом придется долго думать, в чем проблема. К счастью это дело можно исправить в автоматическом режиме. На помощь приходит плагин postcss-flexbugs-fixes.
В примере с calc он найдет в коде фрагменты вроде этого:
№5. Postcss-preset-env
Раз уж мы говорим про поддержку браузерами, то будет не лишним сказать про postcss-preset-env. Раньше ту же роль выполнял cssnext. Этот плагин будет полезен, если вы интересуетесь новыми веяниями в CSS.
Многие из нововведений технически можно реализовать и старыми методами, просто это будет долго, многословно и некрасиво. Preset-env помогает писать код по-новому, экономить на этом время, а потом преобразовывать его в старый надежный вариант. Разумеется, некоторые вещи вроде кастомных свойств совсем не реализованы в старых браузерах, так что там будут применяться фолбеки.
Как можно догадаться по названию инструмента, он напоминает одноименный пресет у Babel. Здесь все так же – много преобразователей, собранных в один стабильный набор. Некоторые преобразования требуют последующее подключение скриптов-полифилов на клиенте, но большинство реализуется чисто средствами CSS. Насколько я понимаю, для Stage2+ скрипты не нужны. Во всяком случае не сталкивался с их необходимостью. Поправьте меня, если я что-то там пропустил.
№6. Postcss-animation
Часто слышу от разных людей (в основном это бэкендеры, которые не очень сильны в CSS), что они хотят использовать отдельные анимации из animate.css, но считают плохой идеей подключать всю библиотеку целиком. Вполне логично. Но в результате они тратят много времени пытаясь повторить эти анимации самостоятельно.
Плагин postcss-animation очень ускоряет этот процесс. Мы пишем только название анимации, например:
А он сам подтягивает из animate.css реализацию и вставляет ее в код.
№7. List-selectors
Когда у вас есть несколько верстальщиков и много стилей, встает вопрос о code review, о том, что было бы неплохо иногда глазами видеть общую картину со всеми селекторами, которые у нас есть. Знать, какие ID используются, есть ли селекторы по тегам или насколько соблюдается принятая методология. Особенно это важно, когда вы проверяете код новичка, который может писать странные вещи, которые формально будут работать, но фактически будут идти вразрез с принятыми соглашениями (далеко не везде эти соглашения хорошо зафиксированы и есть возможность такие вещи автоматизировать). Самому пролистывать многочисленные файлы со стилями, чтобы проверить адекватность селекторов, долго. Нужен способ вычленить их и показать отдельно. List-selectors как раз решает эту задачу.
Точно так же, как и doiuse, этот плагин позволяет использовать свою функцию для подготовки информации к выводу на экран. Можно вывести только то, что интересует, или раскрасить все в разные цвета. Как пример:
В этом примере получится длинный-длинный список селекторов:
№8. Immutable-CSS
Еще одна вещь, за которой стоит следить – это перебивание стилей из сторонних библиотек. Если мы подключили какую-то библиотеку, а потом начинаем для селекторов из нее писать свои стили, то в конечном счете получаем запутанный код, в котором не разобрать, что откуда взялось. Это может приводить к случайным багам, которые потом отнимают слишком много времени на ровном месте. Чем больше раз мы что-то переопределяем, тем сложнее в конечном счете понять, что происходит, хотя сама проблема, которую нужно решить, может быть очень простой. В этой ситуации может пригодиться инструмент под названием immutable-css.
В целом принцип его работы прост: берет файлы со стилями, если находит совпадения по селекторам – начинает возмущаться:
Единственная проблема у данного инструмента – это то, что он не поддерживает не-CSS синтаксис. Так что если в проекте используются препроцессоры, то сравнивать приходится уже собранные файлы. Но в целом, если задача состоит в том, чтобы просто убедиться, что никто случайно не переписал стили из сторонней библиотеки, то это не так важно.
№9. Bye-Bye!
Думаю всем знакома ситуация, когда мы постепенно добавляем какие-то компоненты на работающий сайт. Какие-то из них отправляются сразу в продакшен, а какие-то долго сидят и ждут своей очереди (например сверстать-то мы сверстали, а не бэкенде еще что-то не доделали). Что-то может быть экспериментом или временным решением на праздники. Ситуаций может быть много, но их объединяет то, что у нас набирается куча компонентов, а на боевом сайте используются лишь малая часть из них. Было бы хорошо убрать все, что не используется, из текущей сборки. Это может заметно уменьшить ее размер, а также снизить головную боль в перспективе, когда нужно будет делать редизайн к примеру, и встанет вопрос, что же из всего этого действительно нужно переписывать сейчас, а что — нет.
Есть разные подходы к этому вопросу. На ум сразу приходит uncss. Этот инструмент в автоматическом режиме определяет, какие стили используются на страницах и убирает лишнее. Но на практике это почти всегда приводит к тому, что никто не знает, что реально используется, а что – нет. А еще я все время сомневаюсь, не удалил ли этот инструмент чего лишнего. Но это наверное уже моя паранойя. Хотя.
Bye-bye – это более простой инструмент, которому мы сами скармливаем список селекторов, которые нужно убрать из CSS. Причем можно использовать регулярные выражения. Если вы применяете БЭМ или что-то еще в этом духе, то одной простой регуляркой можно удалять блок со всем, что к нему относится. Bye-bye!
Такой подход оказался довольно удобным. Сразу ясно, какие стили сейчас еще не используются или были убраны за ненадобностью, при этом все исходники на месте, все настройки в одном файле, ничего не потеряется, не вызывает трудностей сделать несколько разных сборок, а главное – решение простое и предсказуемое.
№10. PostCSS-trolling
Все предыдущие инструменты могут незначительно повысить производительность труда ваших верстальщиков, но этот дает просто феноменальные результаты. Очень рекомендую.
Заключение
PostCSS – это хорошее подспорье для верстальщика. Если им не злоупотреблять, конечно. Для многих проблем, отнимающих много времени, есть готовые решения в виде плагинов, и, хотя они зачастую не развиваются и кажутся заброшенными, это не мешает их использовать.