добавил, с ближайшим релизом появится

Вова, почему у меня BH (по инструкции http://ru.bem.info/technology/bh/) не работает в свеже-клонированном project-stub?

Я по инструкции не делал но по нормальному bh с components и core не получилось подружить :( так что какой-то закомментированный код в .enb/make.js project-stub с bh реквестирую, а то у меня руки кривоваты как-то

@weynemeynen Из коробки в project-stub будет один шаблонизатор. Сейчас это BEMHTML. Для кастомизации есть генератор, который умеет задавать наводящие вопросы, но обычно он чуть отстает от project-stub в плане версий используемых модулей и библиотек.

@KlonD90, вот коммит в веточку bh: https://github.com/bem/project-stub/commit/693b63dcbf50210eca67563787d1a0c4ff764ffa, который переводит текущий project-stub на BH вместо BEMHTML, думаю, там все должно быть понятно по диффу.

@tadatuta Спасибо :)

@tadatuta Может быть это... Запилим env.PROJECT_STUB_TEMPLATE_ENGINE ?

@zxqfox тогда каждому пользователю придется таскать все депенды, а конфиги будут еще развесистее. не хочется. нам скорее нужно придумать способ поддержания генератора в актуальном состоянии, чтобы все, кого не устраивает конфигурация project-stub, могли легко собрать свою.

ну и на самом-то деле у нас даже документация есть про то, как все это дело руками наконфигурить при желании: http://ru.bem.info/tools/bem/enb-bh/

@tadatuta Да, твоя правда. Это значит, тесты для генератора надо пилить, да?

@zxqfox результат работы генератора — это конфиг(и) для {bem-tools,enb} make. я вижу 3 способа их тестировать:

1. проверить, что сгенерированный результат равен эталонному (тогда вообще любое изменение == изменение тестов == в них нет смысла)
2. проверить, что сгенерированный результат на каких-то данных при сборке не упал. но все, что мы знаем, когда такой тест отработал — это то, что «что-то как-то собралось». надежность еще та.
3. проверять, что сгенерированный конфиг на каких-то данных при сборке сгенерировал то, что ожидалось. это идеально с точки зрения надежности и даже более-менее воспроизводится при рефакторинге конфигов, обновлении версией зависимостей и прочих минорных апдейтах, но количество комбинацией конфигов помноженное на время вытягивания зависимостей + сборке в сумме занимает годы :(

поэтому у нас сейчас есть сколько-то тестов, но решением задачи они не являются и нужно искать какой-то принципиально другой подход.

@tadatuta Ты прям из пустого в порожнее. Есть же сейчас project-stub, у него есть index.bemjson.js, не достаточно будет тестировать только его? Т.е. нечто среднее между 2 и 3.

@tadatuta, наверное, в тибетских монастырях терпению обучался) @zxqfox что значит тестировать index.bemjson.js? Ты имеешь в виду, проверять то, что на его основе генерируется? Кажется, это как раз то, что у @tadatuta под номером три, с точностью до "каких-то данных".

Единственное, что приходит в голову по делу - параллелить тесты. Кажется, тут может помочь docker.

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

@apsavin ага, думали про кэширование зависимостей, на них действительно большая часть времени уходит. может и придумаем что-то в этом роде.

@apsavin @tadatuta Вообще, тут надо понять, что тестировать. Если правильность конфигов в целом — то это либо собирать все и долго (т.е. 3), либо абы как и (2).

В общем, насколько я понимаю «принципиально новое» это (3) минус заведомо рабочие пакеты (bem-core, технологии, и т.д.). В голову приходят какие-то моки для технологий и блоков для инвариантов. Еще можно каким-то образом проверять наличие и актуальность самих пустышек.