Optional deps for engine
shuhrat opened this issue · comments
In BEM libs all BEMHTML templates depend on i-bem core template, and they are declared in deps file. Tests of those files will pass hence i-bem is attached to the build.
In case if you are writing test to the block which has no such deps, tests will fail, because of absent core templates. So you should add to every testing block deps file
mustDeps: [
{ block: 'i-bem', elem: 'html' }
],
Could you add an option deps to the engines configuration with will attach it to the building deps?
actually maintenance of dependencies is not in responsibility of test framework.
and moreover each block should be independent and not relay on the fact that there's always some other block with needed deps somewhere in a bundle. so we consider it's good that such tests force developers to write better deps-files.
so we have to add into every block that they depend on bem's core templates?
And add this code to every block?
mustDeps: [
{ block: 'i-bem', elem: 'html' }
]yes, as it's really so: all blocks with own templates depend on core templates and cannot work without them.
//cc @mishanga
Дык надо не в депсах это делать, а на уровне технологии сборки.
@mishanga почему про этот конкретный элемент этого конкретного блока в этом конкретном фреймворке для тестирования нужно знать про эту особенность этой конкретной технологии, если с формальной точки зрения это просто допущение, что какой-то другой блок скорее всего уже предоставил этот депенд? почему не хотеть писать честные депенды и не городить локальных костылей?
Потому что это не просто блок и элемент. Это базовые шаблоны, без которых ничего не работает.
@mishanga Т.е. в enb-bemxjst? Предлагается вынести из bem-core?
@zxqfox я бы сказал что не enb-bemxjst, а например enb-bemhtml и enb-bemtree соответственно, по аналогии с enb-bh.
См также обсуждения:
@Guria В целом, 👍
@tadatuta При этом вполне возможно сохранить:
Подход, при котором базовые шаблоны являются именно шаблонами, а не зашиты в библиотеке, позволяет очень гибко влиять на результат — сейчас есть возможность переопределить буквально все. Более того, любой BEMHTML-шаблон — это и есть переопределение базового шаблона.
Я просто не вижу применимости технологий BEMHTML и BEMTREE в отрыве от их базовых шаблонов, т.к. они при этом ничем не отличаются от xjst.
Кроме того текущий подход приводит к тому, что любой блок с bemhtml реализацией, в том числе не реализованный в технологии js, приводит к тому, что по зависимостям тянется весь js фреймворк i-bem.
Дык надо не в депсах это делать, а на уровне технологии сборки.
Тогда технология сборки будет неявно зависеть от bem-core.
Потому что это не просто блок и элемент. Это базовые шаблоны, без которых ничего не работает.
Кажется, поэтому не нужно хранить базовые шаблоны как обычный блок =)
На мой взгляд правильнее выносить базовые технологии в отдельные пакеты: bemhtml и bemtree. В этих пакетах нужно явно указывать от каких версий xjst или bem-xjst они зависят. А также дать возможностью переопределить те места, которые неявно зависят от i-bem.js, например, эскейпинг js-аттрибутов.
@andrewblond 👍
@andrewblond +1
@andrewblond 👍 ❤️
@andrewblond +1
@Guria чтобы не тянулся весь фреимворк i-bem.js нужно писать зависимость по технологии { block: 'i-bem', elem: 'html', tech: 'bemhtml' }
@veged А ведь правда можно унести эту штуку в отдельное место, удобнее же будет
Кажется, поэтому не нужно хранить базовые шаблоны как обычный блок =)
Возникает проблема: как донести до пользователя, что для какой-нибудь bem-core@4.0 нужны базовые шаблоны из пакета bh@3.0, если первый это bower-библиотека, а второй — npm-модуль (а с более ранней версией базовых шаблонов, оно физически не может работать правильно).
Возникает проблема: как донести до пользователя, что для какой-нибудь bem-core@4.0 нужны базовые шаблоны из пакета bh@3.0
Решение:
- при переходе оставить возможность использовать как из какой-нибудь bem-core@4.0 (с deprecate), так и из bower/npm;
- в bower/npm синхронизировать версии и при правках строго пушить в оба места (т.е. git push --tags + npm publish);
- и в следующей мажорной версии (которая случится через год-два, достаточно времени, чтобы донести до каждого) вычистить.
Еще есть вариант пробросить зависимость через сам bem-core (через deps bower, например), тогда для пользователя это будет незаметно, и проблем с синхронизацией не будет (если она вообще будет нужна).
@zxqfox к сожалению не всё так однозначно... в текущей архитектуре есть ряд плюсов, а в альтернативной — минусов
@veged Не спорю, но в текущей есть и ряд ограничений. И сложное становится невозможно.
@zxqfox что именно сейчас не возможно?
@veged Собственно, в этом issue кое-что описано. Например. нельзя явно описать зависимость от нужной версии базовых bemhtml/bemtree, и, соотв., отстуствуют все вытекающие из этого возможности, в т.ч. и использовать в *-tmpl-* пакетах.
Потому что это не просто блок и элемент. Это базовые шаблоны, без которых ничего не работает.
Вот как-то так ;-)
Вообще, я не очень понимаю проблемы в том, чтобы вынести из bem-core базовые шаблоны bemhtml/bemtree, явно их версионировать, и использовать их же как bower зависимости в bem-core. Но кроме этого еще и публиковать в npm, чтобы была возможность использовать в таких пакетах, как этот.
@veged у icon, image и spin тем не менее прописано просто i-bem. Довод, что врядли кто-то будет подключать bem-components только из-за этих 3 блоков я принял, конечно, но не ясно, что мешает уточнить зависимость.
{ block: 'i-bem', elem: 'html', tech: 'bemhtml' } - это https://github.com/bem/bem-core/blob/v2/common.blocks/i-bem/i-bem.bemhtml ? Просто я не вижу элемента html у блока i-bem. Каким образом происходит соответствие?
Возникает проблема: как донести до пользователя, что для какой-нибудь bem-core@4.0 нужны базовые шаблоны из пакета bh@3.0, если первый это bower-библиотека, а второй — npm-модуль (а с более ранней версией базовых шаблонов, оно физически не может работать правильно).
Так для BH это уже так и сделано. bem-core зависит от пакета технологии для enb, который зависит от пакета с шаблонами bh:
https://github.com/bem/bem-core/blob/v2/package.json#L40
https://github.com/enb-bem/enb-bh/blob/master/package.json#L34
https://github.com/bem/bh/blob/master/lib/bh.js
Не понятно, почему же тогда это является проблемой для bemhtml и bemtree. Кроме http://devanswers.ru/a/0h , ничего на ум не приходит. Ну или тогда и bh шаблоны в библиотеку затащить :)
@zxqfox "нельзя явно описать зависимость от нужной версии базовых bemhtml/bemtree" — это потому, что нужная версия является неотъемлемой частью bem-core (так-же как и, например, нужная версия i-bem.js)
проблема в том, что это увеличит количество компонент, которые нужно релизить (двигать каскадом мажорные версии и т.п.)
а ещё текущее положение позволяет иметь несколько параллельных ответвлений — если выделять в отдельный компонент, то будет проблема вида:
- bem-bl использует базовые шаблоны v1.0
- bem-components использует базовые шаблоны v2.0
- bem-bl нуждается в мажорном изменении в своих базовых шаблонах, но не может сделать v2.0 т.к. это уже совсем другая версия, используемая в bem-components
@Guria если у icon, image и spin зависимости более широкие, чем им нужно, то это просто баг
@Guria в том то и дело, наличие BH с альтернативным подходом как раз обнажает проблемы — согласен, что хорошо бы сделать однообразно, вот только не понятно как лучше (поэтому оно пока как исторически сложилось так и лежит)
@veged прямо сейчас ни один из сборщиков не поддерживает depsByTech по-честному :(
текущая схема работы такая: бандловые депсы учитывают технологии из блочных депсов, но модули технологий смотрят в общие «старые» депсы. единственное исключение — это технология клиентского js в bem-tools, в которой захардкоджено, что нужно еще посмотреть в секцию js.bemhtml и сконкатенировать результат компиляции шаблонов на перечисленные там сущности. В ENB же эта задача решается путем создания отдельного бандла с шаблонами и его склейкой (см. https://github.com/bem/project-stub/blob/bem-core/.enb/make.js#L63-L89).
перейти на честную схему в текущем мире — это переписать все модули технологий.
@tadatuta не переписать, а поправить баг ;-)
Возникает проблема: как донести до пользователя, что для какой-нибудь bem-core@4.0 нужны базовые шаблоны из пакета bh@3.0, если первый это bower-библиотека, а второй — npm-модуль (а с более ранней версией базовых шаблонов, оно физически не может работать правильно).
На самом деле все эти проблемы для BEMHTML существуют сейчас, и существовали всегда, по крайней мере при сборке с помощью ENB. В bem-core нигде явно не сказано какую версию enb-bemxjst нужно использовать при сборке BEMHTML и BEMTREE, при этом в enb-bemxjst явно зашита версия bem-xjst.
Ещё помимо bh такая же проблема актуальна и для stylus и для ym, т.е. почти для всех технологий, которые мы используем.
Получается, что наличие базовых шаблонов в библиотеки нам сильно не помогает. На мой взгляд это удобно для решения другой проблемы: i-bem.js неявно зависит от базовых шаблонов (или наоборот). Если мы что-то меняем в i-bem.js то можем в рамках той же версии просто поменять базовые шаблоны и не мучиться с зависимостями.
Тут мне больше нравится подход bh: возможность определить как и куда записывать данные из моды js во время компиляции.
А может стоит решать эту проблему иначе? Cделать BH и BEMHTML независимым от i-bem.js.
Например, можно отказаться от js моды. Вместо этого явно использовать mix: [{ block: 'i-bem' }] и моду attrs, или сделать моду data, которая будет записывать в data-bem атрибут по аналогии с тем, как это сейчас делается с js мода.
но не ясно, что мешает уточнить зависимость.
@Guria, мешает то, что починив такой «баг» мы сломаем сборку всем пользователям библиотек ;)
Решение: при переходе оставить возможность использовать как из какой-нибудь bem-core@4.0 (с deprecate), так и из bower/npm; в bower/npm синхронизировать версии и при правках строго пушить в оба места (т.е. git push --tags + npm publish);
и в следующей мажорной версии (которая случится через год-два, достаточно времени, чтобы донести до каждого) вычистить.
@zxqfox я правильно тебя понял, что ты предлагаешь публиковать инструменты в bower? Я не понимаю как это поможет =)
Я вижу только такой вариант: добавляем мета-информацию о библиотеке, в которой явно говорим, что stylus нужно использовать такой версии, а bemhtml и bh такой. Прямо сейчас пользователи руками могут смотреть в файл с этой мета-информацией и менять зависимости у себя в проекте руками.
проблема в том, что это увеличит количество компонент, которые нужно релизить (двигать каскадом мажорные версии и т.п.)
Для меня это звучит как бонус, а не как проблема =) Потому, что пользователи будут явно видеть, что переход требует мажорных изменений.
bem-bl нуждается в мажорном изменении в своих базовых шаблонах, но не может сделать v2.0 т.к. это уже совсем другая версия, используемая в bem-components
Есть ли в этом реальная необходимость? Более логичным кажется перевести bem-bl на bem-xjst + базовые шаблоны v2.0, выпустив мажорную версию bem-bl, и тогда везде использовать один и тот же BEMHTML.
прямо сейчас ни один из сборщиков не поддерживает
depsByTechпо-честному :(
Я понимаю о чём ты, но мне не нравится термин «по-честному» :) Сейчас всё работает, но требует от пользователя хорошего понимания depsByTech и много ручной работы для сборки каждой технологии по своим уникальным зависимостям.
не переписать, а поправить баг ;-)
Нет, это не про поправить баг =) У текущих сборщиков есть некая архитектура и интерфейс конфигурации. Исходя из этих двух состовляющих невозможно, чтобы depsByTech работали «сами по себе». А вот чтобы это стало возможным, нужно, даже не переписать все технологии, а написать совершенно новый сборщик с знанием о depsByTech, и уже потом для него заново написать все технологии. Поэтому всё же переписать ;)
я правильно тебя понял, что ты предлагаешь публиковать инструменты в bower? Я не понимаю как это поможет =)
Нет, я предлагал вынести из bem-core базовые шаблоны bemtree/bemhtml. Если они нужны в bower (как и bem-core), то пусть это будет bower. Если нужны в npm — нет проблем набрать npm publish.
в которой явно говорим, что stylus нужно использовать такой версии
peerDeps?
@zxqfox, если бы для библиотек было возможно перейти с bower на npm, то это бы решило проблему с неявными зависимостями от технологий и инструментов.
@andrewblond, а ты на какой вопрос ответил? ;-) в bower тоже есть зависимости, и их можно подключать на равне с npm зависимостями. upd в т.ч. и параллельно.
@zxqfox, публиковать все инструменты в bower, как-то странно, да и не всегда возможно.
@andrewblond, я не предлагал все публиковать в bower. Я предлагал публиковать xjst→bemtree/bemhtml И в npm, И в bower. В bem-core прописать bower зависимость, в enb-bem-* использовать либо npm пакеты, либо то, что тянется с bem-core — в последнем случае вообще не вижу минусов, только плюсы.
@zxqfox, помимо bemhtml есть ещё bh, stylus и ym. Их тогда тоже нужно в bower. А ENB пакеты должны думать откуда брать зависимости, а не через родные для них из npm.
По мне это уже звучит как невозможно =)
@andrewblond тогда публикуй и туда и суда, и бери там где надо откуда надо. ;-) В упор не вижу проблемы, она какая-то искуственная.