5 апреля 2016 в 15:04

4 мифа о PostCSS из песочницы

Вы читаете перевод статьи PostCSS Mythbusting: Four PostCSS Myths Busted.

Когда появляется новый фронтенд-инструмент, мы всегда спрашиваем – а нужен ли он нам, что нового он может предложить? Стоит ли тратить время и усилия на его изучение?

С самого начала PostCSS столкнулся с интересной проблемой. Люди не понимали что это и как его использовать. Чтобы завоевать внимание, PostCSS приходилось соперничать с уже привычными подходами Sass и Less. Это соперничество породило некоторые заблуждения.

Давайте развеем некоторые из самых частых мифов о PostCSS и посмотрим, как с его помощью можно усовершенствовать ваш рабочий процесс.


Если вы хотите больше узнать о том, что такое PostCSS и как его настроить, прочитайте статью introduction to PostCSS и возвращайтесь развеивать мифы!

Миф 1: PostCSS — это пре- или постпроцессор


Давайте начнем с, пожалуй, самого большого заблуждения, связанного с PostCSS.

Когда PostCSS только вышел, его позиционировали как «постпроцессор». Большинство первых плагинов PostCSS брали обычный CSS и как-то его улучшали. Этот подход отличался от препроцессорного, при котором особый синтаксис компилируется в обычный CSS.

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

Некоторые PostCSS-плагины берут особый синтаксис и переводят его в обычный CSS, как будто вы работаете с обычным препроцессором вроде Sass. В качестве примера можно привести postcss-nested, который позволяет писать вложенные селекторы, как это сделано в Sass и Less. Другие PostCSS-плагины берут обычный CSS и расширяют его, как, например, делает наиболее известный PostCSS-плагин — Автопрефиксер. Он автоматически добавляет браузерные префиксы в ваши стили.

Есть PostCSS-плагины, которые вообще никак не трансформируют ваш CSS. Вместо этого они анализируют ваш код и подсказывают, как его улучшить. Например, Stylelint используется в качестве линтера CSS, а Colorguard помогает выработать единую цветовую палитру в проекте.

В дополнение к этому, PostCSS парсит как CSS, так и SCSS-синтаксис (и Less, прим. переводчика). Это значит, что вы можете обрабатывать PostCSS-плагинами свои .scss файлы. О том, как это делается, мы поговорим в следующем разделе.

Так что можно развеять первый миф — PostCSS это ни пре-, ни постпроцессор. Это процессор CSS, который может обработать или проанализировать стили на различных этапах вашего рабочего процесса.

Миф 2: PostCSS — альтернатива препроцессорам вроде Sass или Less


Частое заблуждение среди разработчиков – попытка сравнить PostCSS с существующими препроцессорами, вроде Sass или Less.

Я думаю, так произошло из-за того, что первые PostCSS-плагины были нацелены на поддержку возможностей, свойственных препроцессорам: переменных, условных операторов, циклов и миксинов. С ростом PostCSS сообщества возник обширный набор плагинов, представляющих новые возможности, отличающие PostCSS от препроцессоров.

Поэтому, хотя вы и можете использовать PostCSS как альтернативу препроцессорам, вы также можете расширить текущий набор инструментов, добавив новые возможности в свой любимый препроцессор.

PostCSS подходит для парсинга как CSS, так и SCSS-синтаксисаLess, прим. переводчика), а это значит, что вы можете использовать PostCSS как до, так и после компиляции Sass. Например, на текущем проекте я использую PostCSS, чтобы прогнать свои Sass-файлы через Stylelint перед тем, как компилировать их в CSS. А после этого получившийся CSS расширяется плагинами вроде Автопрефиксера и postcss-assets, которые добавляют браузерные префиксы и встраивают графику через data URIs. Так что ваш рабочий процесс может выглядеть примерно так:

using PostCSS

В общем, то, как вы будете использовать PostCSS, зависит от вас. Хотите использовать его отдельным CSS обработчиком — пожалуйста. А если вас полностью устраивает Sass или Less, помните, что PostCSS также может работать бок о бок с этими инструментами, добавляя возможности, которые препроцессор делать не умеет.

Миф 3: PostCSS сделает настройку сложной


Я знаю, о чём вы сейчас думаете. Мир фронтенд-инструментов и так слишком обширен — зачем добавлять ещё один инструмент и делать процесс сборки более запутанным? Вопрос закономерный, но ответить на него вам нужно самостоятельно, в зависимости от проектов, над которыми вы работаете.

Вы можете уже использовать PostCSS, сами того не зная. Если вы используете Автопрефиксер для добавления браузерных префиксов в CSS, то вы уже используете PostCSS. Автопрефиксер — это PostCSS-плагин, который можно добавить в обычные таск-раннеры вроде Grunt и Gulp через плагины grunt-postcss или gulp-postcss. Есть способы это сделать и для других инструментов, таких как webpack — подробности вы найдёте в документации PostCSS.

Если вы раньше не использовали эти плагины для Автопрефиксера, самое время начать. Вы увидите, как просто можно подключить другие PostCSS-плагины. Например, если бы я использовал Автопрефиксер с Gulp, мой код выглядел бы так:

return gulp.src( ['/**/*.css'] )
	// задачи PostCSS для обработки CSS файлов
	.pipe( postcss([
		autoprefixer({
			browsers: [
				'> 5%',
				'last 2 versions',
				'ie > 7'
			] 
		}) // автоматические префиксы для различных браузеров
		… // сюда добавляются любые другие PostCSS-плагины
]) )
.pipe( gulp.dest( CSS_DEST_PATH ) );


Как видите, дополнительные плагины можно просто добавить к Автопрефиксеру в любой момент, когда вы заходите встроить их в свою работу.

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

Добавить PostCSS в свой рабочий процесс не сложнее, чем подключить какой-нибудь плагин Grunt или Gulp. Не пренебрегайте этим лишь потому, что добавляется ещё один шаг сборки: если этот шаг поможет вам улучшить работу с CSS, он стоит того.

Миф 4: PostCSS не предлагает мне ничего, чего не может мой препроцессор


Суть мифа в том, что PostCSS напрямую сравнивают с Sass и Less. А именно, рассматривают плагины, эмулирующие функциональность Sass.

PostCSS сильно вырос за последний год. Появилось множество новых плагинов, и круг возможностей, предлагаемых PostCSS, заметно расширился.

Если вас всё устраивает в текущем препроцессоре и раньше вы не использовали PostCSS, поскольку он предлагал всё то же самое, стоит взглянуть на него ещё раз. Такие плагины, как Stylelint, postcss-stats и doiuse могут обеспечить автоматический анализ вашего CSS, чего не предложит обычный препроцессор.

Также можно оптимизировать код: например, минифицировать SVG и CSS, предоставить более изящные способы обратной совместимости со старыми браузерами, чем миксины.

Если вы хотите поэкспериментировать с CSS Modules, то и тут вам пригодится PostCSS (так как это просто набор плагинов для PostCSS, прим. переводчика).

Главная вещь, о которой стоит помнить при работе с PostCSS — то, что это до сих пор относительно новый инструмент. Пока сообщество растёт, будет создаваться больше плагинов, решающих интересные проблемы CSS. Загляните в каталог доступных плагинов на postcss.parts.

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

Итого


PostCSS — это мощный инструмент обработки CSS, который может улучшить рабочий процесс любого фронтенд-разработчика. Он быстро встраивается в работу и предлагает удобные способы работы с CSS, препроцессорами и написанием кода.

Если вы раньше рассматривали PostCSS и пренебрегли им по каким-либо причинам, я рекомендую вам пересмотреть свои взгляды. Это инструмент, способный улучшить любой процесс фронтенд-разработки.

Автор: Ashley Nolan
Оригинал статьи: http://www.sitepoint.com/postcss-mythbusting/
Андрей Алексеев @aalexeev
карма
59,0
рейтинг 0,0
Фронтенд разработчик
Самое читаемое Разработка

Комментарии (64)

  • +2
    Сейчас как раз работаю с авторами Stylelint над интеграцией моего парсера для LESS. В скором времени с помощью Stylelint можно будет валидировать и LESS!!!

    P.S. Автор приведенного в статье парсера LESS видимо прекратил поддержку и переключился на тестирование моей поделки :)
    • 0
      Спасибо за уточнение! Обновил ссылку на актуальный парсер.
  • +1
    По-моему у PostCSS проблемы с позиционированием. Это название постоянно мелькает перед глазами, но я так и не понял, что и зачем. То ли это убийца sass/less, то ли просто таскраннер вроде gulp/grunt. Так и не хватило мотивации разобраться. Хоть убей, не понимаю зачем мне запускать autoprefixer через PostCSS если я могу просто воткнуть его в gulp.
    • +1
      Вы правы, разницы между gulp-autoprefixer и gulp-postcss(autoprefixer) особо нет — мы перешли на gulp-postcss чтобы самим меньше программировать обёрток и чтобы пользователи быстрее получали обновления.

      Но если у вас несколько плагинов PostCSS — то тут преимущество подхода gulp-postcss очевидно — CSS парситься только один раз, что сильно ускоряет процесс.
    • +4
      Проблема в том, что PostCSS — это новый класс инструментов. В том-то и дело, что это и не просто замена Sass, и не таск раннер.

      Но может вам поможет такое сравнение — PostCSS — это как Babel 6 (который с плагинами и может делать всё что угодно, а не только ES6), только для CSS. У PostCSS даже есть cssnext, который как раз «CSS4» делает.
      • +3
        Спасибо. Всё встало на свои места.
    • 0
      И с названием.
      • 0
        А что не так с названием?
        • +1
          Оно однозначно ассоциируется с постпроцессингом.
          • 0
            Постмодерн или построк тоже только с постпроцессорами? :D

            Пост- — это в значении после.
            • –1
              При чем тут постмодерн? Всё воспринимается в своем контексте.
              В контексте CSS доминируют препроцессоры, они общеизвестны, они де-факто уже базовая технология. Все новые технологии неизбежно сравниваются с ними и противопоставляются им. Какие можно поиметь ассоциации, сравнивая «пост-» с «пре-»? Вполне однозначные.
              • +1
                Ну эта та вещь, которые мы не можем исправить — бессмысленно на неё жаловаться тогда
  • 0
    > могут обеспечить автоматический анализ вашего CSS

    Webpack / Gulp / Grunt + плагины = тот же результат.

    > Также можно оптимизировать код

    Webpack / Gulp / Grunt + плагины = тот же результат.

    При том что Webpack например намного более универсальная вещь и может обрабатывать далеко не только CSS. И вообще очень крутой инструмент для автоматического процессинга ресурсов для фронтенда. Т.е. я могу например изучить PostCSS и будет все равно не хватать каких-то фишек Webpack (например упаковки всех статичных ассетов JS/CSS/HTML/IMG в один файл для компонента интерфеса). Или же могу изучить один раз Webpack и получить все прелести которые есть в PostCSS. Или нет? В данны момент выбираю изучение одного инструмента вместо двух. Но может я что-то реально важное упустил?
    • +3
      PostCSS это по сути совокупность плагинов как подхода к обработке CSS. PostCSS это не отдельная технология, это совокупность плагинов, повторюсь. Используйте ваш любимый сборщик Webpack или Gulp, прогоняйте файлы через отдельные плагины PostCSS ( cssnano — минификатор, autoprefixer и другие) и радуйтесь. Мне в свое время понравилась вот эта презентация: ai.github.io/about-postcss
    • +1
      Сравнивать Gulp/webpack и PostCSS — совсем не корректно.

      PostCSS — это в первую очередь парсер CSS. Используя этот парсер вы и можете создавать плагины. Как чисто в PostCSS, так и для Gulp и webpack.

      На самом деле сам webpack (точнее css-loader) и использует PostCSS, чтобы разворачивать import и url.
    • +1
      Но можно и сравнить сами плагины — например, gulp-postcss с autoprefixer и cssnano внутри или gulp-autoprefixer и gulp-cssnano (оба случая построены на базе PostCSS, просто в первом случае это явно, а в другом нет). В таком случае у gulp-postcss будет огромное преимущество перед отдельными плагинами для Gulp — gulp-postcss будет парсить CSS только один раз. А если у вас просто плагины для Gulp, то каждый из них будет заново парсить CSS.

      А парсинг CSS — это один из самых длинных шагов в обработки CSS. Зависит от задачи, но часто 50-80% (можете поиграться в бенчмарке postcss).
    • +1
      Так ведь для Webpack есть postcss-loader, который довольно органично вписывает PostCSS в экосистему Webpack, какой бы вы подход к сборке не использовали. Он так же легко чейнится как и любой другой loader для CSS.
  • +6
    Забавно, судя по комментариям многие действительно не понимают, что такое postcss. На самом деле сам по себе это парсер + код-принтер. То есть без плагинов postcss просто распарсит ваш css и запишет его обратно. Дальше есть плагины, вроде autoprefixer, которые изменяют css перед записью.
    Это как babel, только в мире css.

    zharikovpro css-loader под капотом использует webpack.
    Miklos потом вам понадобится еще какой-то плагин, который работает поверх postcss и он заново будет парсить css, вместо того, чтобы сделать это внутри postcss. Это тоже вариант, просто не стоит себя обманывать, что вы обходитесь без postcss, он уже внутри gulp-autoprefixer.
    • 0
      Теперь-то всё ясно. Были статьи про использование postcss, и везде приводили элементарные примеры с autoprefixer, которым все пользуются и без postcss, что создавало дополнительное непонимание идеи.
      • 0
        Которым все пользуются не без postcss, а с ним под капотом.
  • +1
    Действительно, много непонимания снялось, в т.ч. благодаря комментам. Спасибо!
  • +1
    Мне кажется или есть проблема с порядком подключения плагинов? ведь каждый плагин работает только исходным файлом и ничего не знает о других плагинах, то есть очередность подключения плагинов имеет значение и сборная солянка плагинов вполне реально не взлетит, а если полетит, то каждое новое подключение плагина это всегда проблема, так как надо идти курить, что же делает уже существующие плагины, верно понимаю? Опять же народ пытается использовать postcss вместе sass/less, и фактически каждый проект получается как новый препроцессор, потому что набор плагинов уникален каждый раз.
    • 0
      Да, это большая проблема — у нас как раз есть решение с помощью событийных плагинов, которые будут в версии 6.0.

      Но а пока обе проблема можно решить просто с помощью пакетов плагинов — не нужно выбирать их самому, лучше взять пакет PreCSS или cssnext.
  • 0
    Слушал ваше (или не ваше) описание postCSS в подкасте Веб-стандарты. Вникать пока было некогда. Понравилась идея о том, что можно написать плагин, который может на входе сразу получить распарсенный CSS и модифицировать в нём только то, что необходимо, передав вожжи следующему плагину. Вопрос: можно ли без крови написать плагин, который будет изменять правила, в которых есть какое-нибудь собственное CSS-свойство (допустим base64: background), таким образом, чтобы в указанном свойстве заменять значение с URI на base64, а само синтетическое свойство удалять? Если я правильно вас понял, то такое должно быть на раз плюнуть. Пример немного грубый, но всё же...?
    Примерно для таких вот костылей он и задуман?
    • 0
      Статью писал и переводил не я :).

      Да, можно и довольно легко.

      Но лучше использовать не свойства, а функцию — тогда base64 можно буде использовать в разных свойствах (и background, и mask). Уже даже несколько написаны: для любых файлов, для SVG со сменой цвета.
      • 0
        Готовые решения не учитывают специфику моих хотелок. Я хочу чтобы весь этот изврат с base64 был только при сборке. Вариант с опционально подключаемым самописным плагином выглядит вкусно.
        • 0
          в webpack с css-loader + url-loader можно сделать чтобы ваш файл автоматически инклюдился в css в виде base64 если он не превышает определенный размер который вы зададите. При этом внутри css будут обычные backround: url('...')
          • 0
            Полагаю, что на первой же не идеально-написанной библиотеке, оно вам задаст жару. К примеру вы подключите какой-нибудь удобный сторонний контрол, а в его CSS будет подключён маловесный спрайт. И этот спрайт будет указан в стилях раз 18. Ух…
            Я пока склоняюсь к ручному указанию какие свойства в каких правилах подключать inline, а какие нет. Вариант с псевдо-свойством мне кажется довольно удобным. Потому что в качестве альтернативы я вижу возможность указывать этот список где-то в конфигах, в отрыве от самих стилей.
            • 0
              В postcss-assets просто добавляется новая функция inline(), которая используется вместо url().
              • 0
                Я хочу чтобы весь этот изврат с base64 был только при сборке

                К тому же inline-ы и в compass-е есть
                • 0
                  А что значит только при сборке? Только при деплое (сборке на продакшене)?
                  • 0
                    Сборки для production-а, да. Во время разработки меня не улыбают все эти тормоза на ровном месте. Это же получается, что при каждом пересохранении SCSS файла я получу повторный inline-инг, который будет считывать каждое необходимое изображение целиком, формирует его base64 вариацию и несёт её в раздутый CSS. Меня и без таких шаманств скорость SCSS не очень устраивает.
                    • 0
                      А у вас старый Ruby Sass? Тогда подумайте о переде на PreCSS на базе PostCSS — он в 28 раз быстрее.

                      Но можно делать и инлайн при деплое. Но только учтите, что тогда кастомное свойство уже не подходит — без сборки оно будет невалидно.
                      • 0
                        без сборки оно будет невалидно.

                        учитывая что это не уходит дальше dev-машины — не вижу никакой проблемы :)
                        • 0
                          Так ваш браузер же не покажет картинку.
                          • 0
                            Вы видимо меня не правильно поняли. В dev:
                            .some {
                              background: url('1.png');
                              _base64: 'background'; 
                            }

                            На production:
                            .some { background: url(data....); }
                            • 0
                              Дело ваше, конечно — можно и так.

                              Но проще будет не писать два раза. PostCSS настолько быстр, что во время разработки его можно запускать на каждое изменение. У нас он отрабатывает меньше секунды (а мы очень много инлайним).
                              • 0
                                PostCSS настолько быстр

                                А причём тут postCSS? Он работает на магии и единорогах? Если программе при каждом запуске потребуется считывать множество файлов целиком и конвертировать их в base64, то оно просто не может не тормозить. Это же изнасилование файловой системы.
                                меньше секунды

                                1000ms это очень медленно.
                                а мы очень много инлайним

                                больше 100 KiB?
                                • +1
                                  Главная причина тормозов — не чтение с файла или base64-кодирование, а парсер Ruby-версии Sass — он написан очень неоптимально.

                                  PostCSS из-за модульной архитектуры проще оптимизировать — всегда видно, где самый затык по скорости.

                                  Да, у нас около 10 файлов по 200—400 КБ.
                                  • 0
                                    по 200—400 КБ

                                    Уговорили, попробую напрямую. Хорошо, что dev-тулы уже умеют показывать base64 значения в сжатом виде… А не как раньше, целиком :D
          • 0
            Автоматический инлайн всех url() — не самое лучшее решение (кстати оно в css-loader делается тоже с помощью скрытого плагина PostCSS) — некоторые картинки не нужно инлайнить, так как они показывается редко. А некоторые большие иллюстрации — нужно.

            Хороший пример — шрифты. Я инлайню главное начертание, а жирное (если оно используется редко) — нет.

            Я поэтому тоже предпочитаю инлайнить вручную с помощью postcss-assets.
            • +1
              Я не совсем понял логику — зачем инлайнить большие иллюстрации? Как раз их бы и сделать внешними ресурсами, чтобы кэширование работало.
              • 0
                Кеширование для CSS тоже работает.

                Конечно, инлайнить нужно не все большие картинки — но иногда важнее заинланить одну большую картинку сверху страницы (которая сразу видна), а куча маленбких картинок снизу проще догрузить лениво.
          • 0
            Вторая проблема (разбил на два сообщения, чтобы было удобнее отвечать) — инлайн SVG. Тут было бы круто при инлайне сразу менять цвет картинки. Поэтому тут авто-url() точно не подойдёт. А вот postcss-inline-svg — лучше.
        • 0
          Может, имеет смысл посмотреть в сторону инжектинга css? Это поможет снизить тормоза при разработке.
          Например, browsersync позволяет сделать так
  • 0
    Если есть парсинг и возможность использовать констукции языков постпроцессоров, то можно ли полностью заменить LESS на postcss + postcss-less? И на сколько это ударит по производительности?
    • 0
      postcss-less только парсит Less, но не применяет примеси или математику. Но в теории это возможно — нужно только написать плагины для всех функций Less.

      Итог, наверное, будет даже быстрее Less. Sass и Less — монолитные огромные проекты, которые сложно оптимизировать. А PostCSS модульный, каждый делает только один модуль и старается делать его оптимально. В итоге у нас сейчас один из самых быстрых парсеров CSS (самый быстрый на JS из тех, кто парсят без ошибок) — а время парсинга один из самых длинных процессов.

      Если говорить только о примесях, вложенности и математике, то PostCSS уже быстрее Less в 4 раза.
  • +1
    Возможно, так станет ещё нагляднее.

    gulp.task('styles', function () {
    var processors = [
    autoprefixer({browsers: ['last 5 versions']}),
    mqpacker, // объединяем «одинаковые селекторы» в одно правило
    cssSimple, // полифилы, хаки для браузеров, удаление ненужного кода
    csswring({preserveHacks: true}) // Minify CSS file with source maps.
    ];

    return gulp
    .src(paths.devroot.scss)
    .pipe(sourcemaps.init())

    .pipe(sass().on('error', sass.logError))
    .pipe(postcss(processors).on('error', onError))

    .pipe(sourcemaps.write("./"))
    .pipe(gulp.dest(paths.webroot.base));
    });
  • 0
    Существуют ли какие-либо идеи с подсветкой синтаксиса? На мой взгляд, это мешает распространению. Разработчики предлагают самостоятельно прописывать правила подсветки в IDE, выходит, что настраивать надо под каждый сторонний модуль, инструкции которого имеют расхождение с базовым css/scss/less синтаксисом.

    Аннотации?!
    • 0
      Для Атома и Саблайна есть плагины с подсветкой.

      Для ВебШторма бы написали — но команда Шторма нормально не открывает модуль и сама писать не хочет. Но там можно выставить подсветку SCSS и всё будет нормально.
  • 0
    Поможет ли эта штука заменить «Compass»?
    • 0
      Полностью. Автопрефиксер заменяет примеси с префиксами. postcss-assets заменяет инлайн картинок.

      Команда Compass уже прекратила его развитие и тоже считает, что Автопрефиксер работает на порядок лучше.
      • 0
        Команда Compass уже прекратила его развитие и тоже считает, что Автопрефиксер работает на порядок лучше.

        Звучит бредово. Кто-то использовал compass только из-за миксинов автопрефиксера? :) Дурь же…
        Скорее вы хотели сказать, что "postCSS работает на порядок лучше", ибо там нужна уйма плагинов.
        Кстати говоря, я думаю не стоит повсеместно применять выражение "на порядок". Это ж в 10 раз лучше. В 10, Карл, в 10!
        • 0
          Вы не путаете Compass и Sass? Sass — это тот язык, который даёт вам примеси, переменные и циклы поверх CSS. А Compass — просто набор примесей для Sass. Большая часть этих примесей была про префиксы. Ещё часть была про спрайты (это тоже есть в PostCSS).

          Собственно, на прошедшем SassSummit Крис Эпштейн и заявил, что Compass закрыт — будут только мелкие обновления типа безопасности.

          Ну и в Париже на CSSConf он мне это подтвердил.
          • 0
            Вы не путаете Compass и Sass?

            Вроде не путаю. Тут в разделе All Ruby Based Functions под сотню пунктов. Я, правда, из них пользуюсь всего 4-5. Примесями я в нём практически не пользовался.
            • 0
              Их тоже можно перенести на PostCSS.

              Например, функция работа с цветом уже стала частью «CSS4» — и тут лучше использовать стандартный синтаксис из будущего, с помощью cssnext на базе PostCSS. Это как ES6 для многих лучше CoffeeScript.
              • +1
                Этим postCSS и подкупает: можно добавить всё по своему вкусу, включая то, чего нет из коробки, написав руками. Аля grunt для css.
      • +1

        В общем вы убедили меня попробовать разобраться с PostCSS и "выбросить" Compass. Здесь я опишу свой опыт внедрения.
        Сейчас я работаю над проектом, построенном на Django. Всю "статику" я положил в папку public/static/, в которой еще 6 папок: css, fonts, img, js, maps и sass. Перво-наперво установим NodeJS в систему, потом переходим в папку с проектом и спомощью комманды: npm init создаём package.json. Далее через npm install ставим "gulp" (его понадобилось установить два раза — глобально и локально). Далее ставим такой набор модулей: gulp-sass, postcss-scss, gulp-postcss, autoprefixer, postcss-assets, postcss-font-magician, cssnano, postcss-inline-svg, gulp-sourcemaps, gulp-cached.


        Далее также в папке проект создаём файл gulpfile.js, в него помещаются задачи для Gulp-а, я для себя сделал так:


        'use strict';
        
        var gulp = require('gulp');
        var sass = require('gulp-sass');
        var syntax = require('postcss-scss');
        var postcss = require('gulp-postcss');
        var autoprefixer = require('autoprefixer')({browsers: ['last 2 versions']});
        var assets = require('postcss-assets')({basePath: 'public/', loadPaths: ['static/img/', 'static/fonts/']});
        var fonts = require('postcss-font-magician')();
        var cssnano = require('cssnano')();
        var inlineSVG = require('postcss-inline-svg')();
        var sourcemaps = require('gulp-sourcemaps');
        var cache = require('gulp-cached');
        
        gulp.task('devel', function () {
            var pre = [assets, inlineSVG];
            var post = [autoprefixer, fonts];
            return gulp.src('public/static/sass/*.scss')
                .pipe(cache('handled'))
                .pipe(postcss(pre, {syntax: syntax}))
                .pipe(sourcemaps.init())
                .pipe(sass().on('error', sass.logError))
                .pipe(postcss(post))
                .pipe(sourcemaps.write('../maps'))
                .pipe(gulp.dest('public/static/css'));
        });
        
        gulp.task('product', function () {
            var pre = [assets, inlineSVG];
            var post = [autoprefixer, fonts,cssnano];
            return gulp.src('public/static/sass/*.scss')
                .pipe(postcss(pre, {syntax: syntax}))
                .pipe(sass().on('error', sass.logError))
                .pipe(postcss(post))
                .pipe(gulp.dest('public/static/css'));
        });
        
        gulp.task('watch', function () {
            gulp.watch('public/static/sass/*.scss', ['devel']);
        });
        
        gulp.task('default', ['watch', 'devel']);

        Как видно из кода я использую две основные задачи, первая — devel, для генерации CSS-стилей во время разработки, вторая для подготовки стилей чтобы отправить в "продакшн", пришлось сделать две так как для минификации стилей я использую cssnano, а он у меня отрабатывает примерно за 20 секунд (не могу сказать много это или мало).
        Для разных разделов сайта пишу стили в отдельных файлах (потом django-compress их склеивает в один) и чтобы gulp не обрабатывал зря файлы, которые я "не трогал" использую для этого модуль gulp-cached.


        Плагины для PostCSS я разделил на две группы: в первой работают плагины перед компиляцией SASS в CSS, во второй после компиляции. Это я сделал для того, чтобы например, получать размеры картинок и присваивать их переменным (чтобы потом можно было проделывать арифметические операции).


        Тепрь в консоли можно дать команду: gulp (или gulp watch) и спокойно кодить стили на SassyCSS (Ураа, я сделал это :-)).
        В итоге теперь можно писать примерно такой "стиль":


        .table-of-contents {
          $margin-from-icon: 15px;
          $left-pad-item: 70px;
          $marker-width: width('inline/marker_ice.png');
          $marker-height: height('inline/marker_ice.png');
          padding-left: $left-pad-item + $margin-from-icon + $marker-width;
          & > li {
            h3 {
              text-indent: -1 * ($marker-width + $margin-from-icon);
              vertical-align: baseline;
              &::before {
                content: ' ';
                display: inline-block;
                width: $marker-width;
                height: $marker-height;
                margin-right: 15px;
                vertical-align: -5px;
                background: no-repeat inline('inline/marker_ice.png');
              }
            }
          }
        }

        и вся компиляция в "CSS" происходит очень быстро.

        • 0
          советовал бы поглядеть плагины gulp-if, чтобы не копипасть скрипты для сборки отдельно
          gulp-plumber — для навешивания обработчика ошибки на весь поток, а не только на gulp-sass
  • 0
    Из обсуждений у меня сложилось впечатление, что если, помимо nested правил из SCSS, я ещё использую ещё циклы, миксины, переменные, то postCSS мне придётся запускать уже поверх сгенерированной Sass-ом CSS-ки? Или сам Sass тоже можно подключить как один из плагинов? Как вы эти проблемы решаете?
    • +1
      Примеси, переменные, математика и цикли есть в виде плагинов. Проще взять уже готовый набор плагинов PreCSS, в котором всё это есть
      • 0
        Похоже, что всё что мне нужно есть. Хороший повод попробовать на досуге.
        • 0
          Если не мешать сложной логики для стилей (да и не нужно в стилях мешать ложную логику, css должен быть прозрачным), то PreCSS хорош и быстр.

          Ещё очень интересен cssnext. Поначалу напрягает синтаксис, но это дело привычки. Сначала кажется странным, что для математики надо использовать calc (при парсинге значения вычисляются и подставляются), а для переменных, особых медиа-условий и цветовых функций — новый синтаксис. Однако, со временем это станет стандартом, почему бы не привыкать заранее.

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.