search

awinogradov / enb-postcss

PostCSS for ENB
11 stars 7 forks source link

Одновременное использование file.post.css и file.css #34

Closed aliosv closed 7 years ago

aliosv commented 7 years ago

причина https://github.com/awinogradov/enb-postcss/blob/master/techs/enb-postcss.js#L27

https://github.com/awinogradov/enb-postcss/blob/master/techs/enb-postcss.js#L31 фильтрация не происходит, т.к. basename равен .../file.post и .../file соответственно

awinogradov commented 7 years ago

Кажется так и должно быть. В чем именно проблема?

aliosv commented 7 years ago

https://github.com/awinogradov/enb-postcss/blob/master/techs/enb-postcss.js#L21

проблема в том, что в собранном css будет и b1.css и b1.post.css, т.е. дублирование стилей

awinogradov commented 7 years ago

Технология работает именно так https://github.com/awinogradov/enb-postcss/blob/master/techs/enb-postcss.js#L14. Ты можешь передать список расширений, который тебе нравится.

aliosv commented 7 years ago

На проекте одновременно могут использоваться post.css и css. В этом случае из bem-components получим дубликат стилей(там исходники в post.css и скомпилированный css сразу).

В коде явно написано, что если для бэм-сущности есть post.css - взять его, остальные технологии отфильтровать.

awinogradov commented 7 years ago

@aliosv ты уже в 3 раз пишешь одно и то же) я понимаю твою боль) но причем тут enb-postcss? Если есть чего предложить, предлагай)

aliosv commented 7 years ago

я не пойму где проблема. 1) твои слова противоречат коду, который написан, в этом случае одновременная поставка двух технологий в bem-components - ок. 2) и наоборот, если использовать одновременно разные технологии для одной сущности, то зачем в bem-components дублирование стилей, и в коде написана проверка про post.css, которая сейчас не работает

awinogradov commented 7 years ago

Во-первых, bem-components никакого отношения к текущему репозиторию не имеет. Все претензии туда. Во-вторых, что тебя останавливает от передачи параметра с единственным расширением? В-третьих, напиши уже чего ты ожидаешь?

aliosv commented 7 years ago

что тебя останавливает от передачи параметра с единственным расширением?

использование на проекте обеих технологий

напиши уже чего ты ожидаешь?

ожидал, что при .useFileList(['post.css', 'css']) из b1.post.css и b1.css будет использоваться только первый

keep just first of b1.post.css and b1.css

этот комментарий означает брать только post.css если есть b1.post.css и b1.css, или брать только первые файлы для обеих технологий? В первом случае - не работает, во втором случае - зачем нужна эта фильтрация(что и сбивает с толку), если не может быть двух одинаковых файлов?

awinogradov commented 7 years ago

ожидал, что при .useFileList(['post.css', 'css']) из b1.post.css и b1.css будет использоваться только первый

Все enb технологии работают не так. Они принимают на вход список всего и клеют/обрабатывают/что угодно. Ничем не запрещено написать и css и post.css для одной сущности с разным содержимым. В твоих ожиданиях то что будет в css не приедет никогда.

aliosv commented 7 years ago

топчемся на месте

Все enb технологии работают не так. Они принимают на вход список всего и клеют/обрабатывают/что угодно.

верно, ожидаемое поведение - нестандартная логика

Ничем не запрещено написать и css и post.css для одной сущности с разным содержимым.

именно поэтому используются обе технологии одновременно

В твоих ожиданиях то что будет в css не приедет никогда.

именно, т.е. для сущности должен быть или css или post.css. Это решает проблему с bem-components(сделай bower install bem-components@5.0.0 и посмотри на сорцы в папке design, поймешь суть проблемы).

Допустим, наличие в bem-components файлов post.css и css с ОДИНАКОВЫМ содержимым их багой/фичей, тогда зачем тут написан этот код? https://github.com/awinogradov/enb-postcss/blob/master/techs/enb-postcss.js#L21-L38

awinogradov commented 7 years ago

именно, т.е. для сущности должен быть или css или post.css.

Нет, это необязательно. У меня может быть еще рядом ie.css, ie9.css, kostyl.css и все это надо склеить и обработать. Матчится на post.css и игнорить css не верно. Как и не верно, что только одна технология css на одну конкретную сущность. Вероятно этот код был добавлен с подобной целью, но лучше спросить у автора https://github.com/awinogradov/enb-postcss/pull/25/commits/6a82eec75879ac4007ab395b9939bfbcc9ed53cb @tadatuta

Но еще ты можешь настроить в сборке не одну технологию enb-postcss, а целых 2, 3, 4 или сколько угодно еще. В одной обработывать один набор расширений, а в другой любой другой. Как и, видимо, совершенно не обязательно .css обрабатывать с помощью enb-postcss в твоем случае. Есть целый набор других технологий про это https://github.com/enb/enb-css.

aliosv commented 7 years ago

в указанном коммите https://github.com/awinogradov/enb-postcss/pull/25/commits/6a82eec75879ac4007ab395b9939bfbcc9ed53cb как раз пропускается только один **.css из всех возможных, дальше эта логика ломается https://github.com/awinogradov/enb-postcss/commit/c966903eadd238c0b3b33235e4b08f00ef971e03 и весь блок фильтрации списка файлов становится бесполезным

@tadatuta, проясни пожалуйста ситуацию.

tadatuta commented 7 years ago

@awinogradov ох, таки да, ожидалось, что захавается только первый найденный суффикс. в мире gulp-а в итоге это решается отдельным плагином https://github.com/tadatuta/gulp-one-of

Здесь нужно додумать. Проблема на самом деле критичная.

aliosv commented 7 years ago

как вариант:

upd. плохо, теряется порядок

awinogradov commented 7 years ago

Как по мне таки надо просто поставлять в npm/bower bem-components в css only. Никто же не раздает написаное на es6 в исходниках. А если мне надо я иду на гитхаб. Технически сейчас enb-postcss работает верно и тот код можно удалить.

aliosv commented 7 years ago

Как я понял, они делают поставку сорцов из-за rebem-css. Я бы избавился от собранного css, или, если оставлять, то логично компилировать в двух вариантах нейминга, не так ли?

upd. поставлять в dist - оба варианта нейминга, в bower - только сорцы

awinogradov commented 7 years ago

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

awinogradov commented 7 years ago

Поставка в исходниках не будет работать корректно еще и из-за наличия кастомных плагинов postcss. Это обязательное требование перед использованием. Из коробки не заведется.

aliosv commented 7 years ago

Технически сейчас enb-postcss работает верно и тот код можно удалить.

pr https://github.com/awinogradov/enb-postcss/pull/35

tadatuta commented 7 years ago

На самом деле вопрос не такой уж однозначный. enb-stylus всегда работал именно в режиме one-of (см. https://github.com/enb/enb-stylus/blob/master/techs/stylus.js#L156-L198) и переход на postCSS предполагал, что это поведение сохранится. Что и было реализовано в моем PR, а потом с очередным минором это поведение было изменено.

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

Предлагаю добавить опцию oneOfSourceSuffixes, которая бы получала массив либо массив массивов. Например, конфиг

{
    sourceSuffixes: ['post.css', 'ie.post.css', 'styl', 'ie.styl', 'css', 'ie.css'],
    oneOfSourceSuffixes: [['post.css', 'styl', 'css'], ['ie.post.css', 'ie.styl', 'ie.css']]
}

означает, что для исходной структуры вида

b1/
    b1.post.css
    b1.styl
    b1.css
    b1.ie.post.css
    b1.ie.styl
    b1.ie.css

в сборку попадут только b1.post.css и b1.ie.post.css.

По умолчанию oneOfSourceSuffixes не задано, т.е. получаем стандартное поведение, а в случае использования позволяет выразить любое произвольное поведение.

@awinogradov, если тебе ок, готов запилить PR.

awinogradov commented 7 years ago

@tadatuta звучит логично, давай сделаем

aliosv commented 7 years ago

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

если делать oneOfSourceSuffixes, тогда ломается порядок блоков, т.к. придется клеить из двух потоков.

Предлагаю: 1) oneOfSourceSuffixes не делать, это позволит сохранить порядок блоков при сборке 2) разделить сорцы на разные уровни в исходном пакете, подключая нужный в make файле. Порядок сущностей сохраняется, + доступны все прежние фичи: post-css для кастомного нейминга/возможно скорости, и css для несовместимого процессора на проекте.

awinogradov commented 7 years ago

Это не повлияет на порядок. Файлы приходят в одном потоке и будут обработаны последовательно через фильтр. Вова пришлёт PR посмотрим. Решение хорошо тем, что не влияет на дефолтное поведение и параметром позволяет кастомизировать список технологий. Плюс доп телодвижений для компонентов не надо. Но я бы завёл ишью в компоненты на доделку дистрибьюции в пользу скомплиненных стилей. Пожалуй я и заведу:)

tadatuta commented 7 years ago

Мы совершенно сознательно поставляем сорцы ради кастомного нейминга. А порядок таки сохранится, да.

awinogradov commented 7 years ago

@tadatuta давай про компоненты тут https://github.com/bem/bem-components/issues/1994

aliosv commented 7 years ago

разобрались, так порядок сохраняется

lib/
    b1/
        b1.css
        b1.post.css
proj/
    b1/ - вот тут должно быть что-то одно: css или post.css
        b1.css
        b1.post.css