нужно всё нормально запрограммировать ;-) можно сделать это в bem-tools, вот только у нас рук нет :-(

Нормально запрограммировать это как кнопка «сделать отличное нечто».

В свое время с архитектурой бем-тулзов я разбирался с неделю, и это были только поверхностные изыскания. В enb даж не знаю стоит ли лезть. Хотелось бы понять что конкретно делать-то надо. Обсуждалось же не раз, если я правильно понял. Может где-то что-то есть что почитать как это предполагалось сделать.

Есть еще такой момент, что часть людей переехало на enb, и с разработкой самих тулзов непонятки. Вот и непонятно теперь куда движемся.

не переживай, ничего особо конкретного не наобсуждалось ;-)

@veged Окей, тогда у меня вопрос по сборщику, никто еще не начал?

@zxqfox

1. В bem-tools в базовом модуле технологий, от которого наследуются все остальные модули для сборки технологий блоков, реализован метод validate. Он на вход принимает путь до собираемого файла и список файлов, от которых он зависит. Дальше список зависимостей сравнивается со списком, закешированным после предыдущей сборки. Зовется validate() из getBuildResults(), где список зависимостей собирается на основе getBuildSuffixes(). В текущей реальности можно более-менее легко (наверное) закостылять, чтобы сборка browser.js+bemhtml зависила не только от суффиксов js и browser.js, как это сделано сейчас, но и от bemhtml. Но это в любом случае будет вызывать инвалидацию при изменении любого блока в технологии bemhtml, а не только от тех, от которых зависит browser.js по depsByTech. Если совсем костылями-костылями кастомно для каждой технологии отдельно, то можно список файлов-зависимостей фильровать руками.
2. Если говорить про ENB, то там работа с depsByTech для каждой разбита на несколько ручных этапов, захардкодженных прямо в конфиге сборки проекта: а) собрать и положить на файловую систему основную технологию (в данном случае browser.js). б) собрать отдельный bemdecl.js на основе нужного поля в depsByTech (для нас это bemhtml). в) собрать на основе этого bemdecl.js нужную технологию как если бы это была обычная сборка бандла и положить на файловую систему. г) сконкатенировать результаты а) и в) Кажется, что если над этим навернуть какой-нибудь хелпер, то с этим даже можно как-то жить. По крайней мере инвалидация там (вроде) работает как нужно.

@tadatuta Ой... Спасибо за подробности. Весьма кстати ;-)

@veged @tadatuta Выложу свои мысли.

1. Я все-таки думаю, что допиливать придется, и весьма много. Как минимум свою библиотеку-обертку над fs, которая будет уметь читать бем-структуры и следить за инвалидацией в памяти, уметь сохранять на диск, если надо.
2. Естественно, придется допиливать и сам сборщик, и резолвер зависимостей. А это и deps, и level, и make.
3. При чем, относительно depsByTech, почему-то думаю, что это должно реализовываться иначе — итоговой фильтрацией по входящей технологии, а не как сейчас. Возможно, то, как это сделано сейчас, было проще или должно было быстрее работать, но в общем случае это не дает сильного прироста производительности, а в частных это сложно для понимания.
4. Все еще не вижу, почему нельзя или не стоит выносить в независимый модуль чтения всего проекта в память, чтобы после работать с бем-сущностями исключительно через него. В тулзах это делает и apw, и отдельные технологии, что на мой взгляд крайне неверно. Из проблем вижу только прямые обращения к диску в технологиях и всяких кастомных решениях — для этого можно экспортировать прокси объект с интерфейсом нодового fs, чтобы было меньше геморроя. Но несовместимость появится, без этого никак (или можно как-то?)
5. Есть лайт вариант попробовать начать с наворачивания хелпера, описанного @tadatuta, но тогда есть много вопросов по enb. ;-( И это все равно временное решение.

@zxqfox, сейчас активную разработку на ENB ведет @andrewblond. его стараниями появилась целая куча модулей: https://github.com/enb-bem так что задавай вопросы, форум он читает. ну и более хардкорные варианты тоже можно обсуждать с ним — он сейчас самый погруженный в контекст сборки участник команды.

@tadatuta я наверное не туда пишу, но пока везде молчит ;-)

В общем, у меня такое ощущение, что:

• из технологий нужно выделить некие процессоры, которые умеют делать преобразования. либо в колбек, либо промисом (в енб технологии хранят данные о таргетах, не понимаю зачем);
• работать процессоры должны с хранилищем, которое хранит данные о блоках, их зависимостях, содержимом;
• остальные технологии лучше переименовать в таски, например, чтобы сохранять все на fs. таск может делать это через хранилку и конфиги, и описать его использование можно, например, через .on('something-processed');
• элементы в хранилище объекты типа vinyl — мета-информация, в идеале никаких обращений к диску/сети из него;
• для конфига делаются хелперы, позволяющие упростить зависимости технологий (что из чего собирается) [тут хочу подчеркнуть, что в enb конфиги пишутся в императивном стиле], там же хранятся уровни, которые рулят их неймингом, маппингом на fs, если нужно загружать/сохранять, и они являются частью проекта/библиотеки;
• сборка, в итоге, будет описываться в виде: ('processor', '.dest', ['tech1', 'tech2', 'tech3']), например, ('html-from-bemjson', '.html', ['.bemjson', '.bemhtml']). Аналогично можно будет рядом описать '.html', ['.bemjson', '.bh'] и сборка .html будет происходит из имеющихся технологий в блоках, без требования конкретных bh/bemhtml/anythingelse;

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

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

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

итого, примерный конфиг будет похож на .enb/make.js, но должен будет разделить techs на processors/converters и tasks/commands. processors — преобразуют входные данные в нечто еще, tasks — выполняют служебные задачи, не относящиеся напрямую к bem-предметной области, в т.ч. копирование файлов.

В такой схеме deps вполе легко вклинивается и используется дирижером, как task, или даже без напрямую. Равно как и levels.

p.s. Возможно, это похоже на небольшой рефакторинг enb.

/cc @andrewblond

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

Что касается реализации depsByTech, то она конечно же хромает. По крайней мере в ENB API получения деклараций по технологии выглядит очень неочивидным. Основная причина тому — инвалидация кэша.

В ENB все технологии (кроме базовых) работают на ?.files/?.dirs таргете. Чтобы с точки зрения использования всё выглядело красиво, нужно раскрывать bemdecl в несколько deps по технологиям, а потом сформировать ?.files таргет так, чтобы инстанс внутри него отдавал для каждой технологии свой набор файлов. Это всё так или иначе реализуемо, но если мы поменяем одну tech-зависимость у одного блока, то ?.files таргет инвалидируется полностью, и пересоберутся таргеты всех технологий, а не той, которую мы меняли.

Сейчас это всё можно сделать руками: bemdecl -> deps -> files -> bemdecl-from-deps-by-tech -> deps -> files. Тогда каждый такой ?.files таргет будет правильно закэширован, но только указывать его нужно будет опять же руками для каждой технологии свой.

если вы хотите задать вопрос команде, то ставьте еще и метку asktheteam ;) спасибо!