Ребята, если вы чувствуете в себе силы помочь нам и дописать технологию enb-css
, чтобы она научилась поддерживать произвольные плагины postCSS — приходите в https://github.com/enb/enb-css/issues/9!
Что есть сейчас: отличная технология для сборки стилей с покрытием тестами и хорошей документацией. Она уже сейчас умеет postCSS для автопрефиксера, но по нелепой случайности не позволяет добавлять другие плагины. В результате приходится дополнительно подключать технологию про postCSS и заново парсить стили. Помогите сделать хорошо!
@blond, сможешь описать API в issue?
@tadatuta а чем https://github.com/awinogradov/enb-postcss не подходит? Тем более что у него есть пользователи?
@awinogradov по моей оценке довести
enb-postcss
до состоянияenb-css
дороже, чем добавить вenb-css
поддержку кастомных плагинов. Потребуется:Ну и пользователей у
enb-css
примерно в 20 раз больше, если верить статистике npm.Но если все это появится у
enb-postcss
раньше, чем поддержка плагинов уenb-css
— тоже норм.@tadatuta в
enb-css
таки тоже есть что поделать ;) технология включает как минимум 3 плагина по-умолчанию, на порядок и настройки которых ты не очень то можешь влиять. В некотором количестве случаев такая архитектура будет мешать подключению произвольных плагинов. Собственно по этой причине и появилсяenb-postcss
, который реализует сам движок для работы с postcss и больше ничего.Надо в enb-css оставить подключение этих плагинов для обратной совместимости, но если указаны явно плагины postcss — не использовать их, а использовать только то, что указано.
Смахивает на мажор, который будет очень похож на enb-postcss ;)
Смахивает на мажор, который будет очень похож на enb-postcss ;) Кажется можно это минором сделать. -- the end
@vithar я не понимаю зачем делать то, что уже есть. Может таки лучше дотянуть доки и тесты и все? Будет 2 явных технологии про понятное.
@vithar я не понимаю зачем делать то, что уже есть. Может таки лучше дотянуть доки и тесты и все? Будет 2 явных технологии про понятное. Если доки и тесты проще — не вопрос. -- the end
Если и делать что-то, то добавить технологию
postcss
в пакетenb-css
.@awinogradov, видишь в этом смысл?
Только в количестве пакетов и уменьшении реализаций от сообщества)
##
Anton Winogradov winogradovaa@gmail.com
@blond если базовая технология из
enb-css
в любом случае прогоняет стили черезpostcss
, почему просто не дать возможность досыпать туда плагинов и не плодить сущностей?@tadatuta чтобы не было конфликтов между плагинами. Но лучше обсуждать не абстрактно, а на примерах.
Тебе же это где-то нужно?
@blond я хочу буквально следующего: https://nda.ya.ru/3RkBS2, но за один хоп
Как кейс, вроде бы, вполне годно. Он звучит как «хочу кастомный CSS».
Тут можно идти в двух направлениях:
nested: true
,cssnext: true
и т.д.Минусы первого в том, что все эти кейсы надо поддерживать, добавлять зависимости в пакет и т.д. Да и пользователям придётся искать в документации как включаить тот или иной плагин.
Минусы второго в том, что мы не можем влиять на порядок плагинов, не можем отключать
postcss-url
иpostcss-import
. Но, кажется, это очень редкий случай, для которого можно положить технологиюpostcss
рядом.Первый вариант с опциями на каждый кейс мне точно не нравится, а про второй предлагаю обсудить.
Почему нельзя сделать буквально следующее: добавить опциональный параметр в API, который будет содержать произвольный массив postcss-плагинов (именно в нужном порядке)? При этом явно задекларировать, что если массив передан, то он выключает действие существующих опций, использующих postcss. Плюс показать в ридми, как добиться поведения по умолчанию с помощью новой опции, чтобы было от чего отталкиваться.
Это неочевидное поведение. Если тебе не нужны те настройки и опции, которые уже есть сейчас в
css
технологии, то тебе и технология эта не нужна, а нужна отдельнаяpostcss
технология.Я бы скорее сказал, что вытаскивание плагинов на уровень API — это более очевидное поведение, на которое пользователь сможет осознанно влиять при необходимости.
Можно сначала добавить поддержку массива плагинов обратносовместимым способом и плевать в консоль варнинги, что завязанные на postcss опции деприкейтед. А в мажоре совсем их оторвать и будет совсем хорошо: одна универсальная технология, которая позволяет каждому сделать красиво.