@pavelpower

1. В схеме есть ошибка. Декларацией для сборки служит bemjson.js или, если BEMJSON генерируется динамически, bemdecl.js. Декларация представляет список сущностей, которые присутствуют в бандле (странице). Далее у каждой сущности могут быть свои собственные зависимости, описанные в блочных deps.js-файлах. Поэтому bundle.deps.js — это не первый шаг сборки, а второй. Он представляет собой список сущностей с учетом зависимостей. А дальше в зависимости от технологии, которую требуется собрать, может происходить конкатенация/компиляция/оптимизация или какая-то более сложная логика (stylus → css → autoprefixer → clean-css). Подробнее и с примерами можно почитать, например, здесь.
2. Есть неточность с формулировкой. Традиционно сборка собирает все не «обратно в блоки», а в бандлы (от англ. bundle — «комплект»). Они как раз и представляют собой место, где по декларации собрано все из блоков и готово к использованию — ту самую «ожидаемую структуру».

Но в целом идея верная — bem-tools (и в меньшей степени ENB) заточены исключительно под предметную область БЭМ и делать с их помощью какие-то общие действия типа перекладывания файлов произвольным образом не очень удобно. Поэтому вполне здраво комбинировать их с чем-то еще (хоть просто в package.json в секцию scripts написать однострочник типа bem make && cp desktop.bundles/merged/_merged.css app/css/ && cp desktop.bundles/merged/_merged.js app/js/).

Похоже на yet another post о том, как странно, что bem-tools и ENB кладут результат компиляции в папку с файлами, которые предполагается править руками. С определенной точки зрения, если смотреть сквозь призму БЭМ-методологии, это логично, но на практике неудобно. Это еще можно решить костылем с симлинками, если бандл один, но в типичном проекте их, конечно, больше. С bem-tools тут, кажется, ничего не поделать, но, может быть, ENB можно научить создавать дублирующую структуру бандлов где-нибудь рядышком для хранения результатов компиляции? Думаю, ради такой фичи я бы слез с bem-tools.)

С bem-tools тут, кажется, ничего не поделать, но, может быть, ENB можно научить создавать дублирующую структуру бандлов где-нибудь рядышком для хранения результатов компиляции? Думаю, ради такой фичи я бы слез с bem-tools.)

В ENB есть технология file-copy. Достаточно объявить директорию в которую нужно скопировть файл нодой, а в опциях технологии указать путь до бандла, из которого нужно скопировать.

config.node('app/js', function (nodeConfig) { // объявляем ноду
    nodeConfig.addTech([require('enb/techs/file-copy'), {
        source: '?.js',                       // копируем файл index.js
        sourceNode: 'desktop.bundles/index',  // из бандла
        target: 'index.js'                    // в app/js/index.js
    }]);
});

Близко, но не то: все равно "мусор" будет лежать в папках бандлов.

@tadatuta, все бы хорошо. Но дело в том, что у нас в проекте нет bemjson.js. По этому входной входной точкой служит служит bemdecl.js bemjson еще нужно внедрять и объяснять, что это и почему.

@apsavin, Дело еще в том, что при большом проекте, часто не желательно пересобирать файлы исходники которых не менялись. Тогда выгоднее держать результат компиляции именно в папке блока. Ибо при сборке ты можешь менять слой переопределения который содержит другую бизнес-логику, например сборка для разных устройств. Тогда в результирующей папке ты будешь изменять результат компиляции, и ты вынужден вместо обычного копирования, или создания символической ссылки, компилировать исходник заново, а это уже на много затратнее.

@apsavin, @andrewblond Было бы хорошо иметь возможность при необходимости создавать копию структуры со сборками, чтобы не какать в исходники.

@pavelpower Я об этом и написал выше.

выгоднее держать результат компиляции именно в папке блока

имеется в виду, бандла, я полагаю?

Можно делать копию во временную папку для каждого бандла (по названию, например), затем там делать сборку, туда складывать все, а затем копировать оттуда в итоговую папку только нужное (явно указанные таргеты). Не уверен, что есть проблемы с таким способом (например, в bem-tools может быть беда с минифицированными, в enb хз), но тогда непонятно, почему этого раньше никто не сделал, если только из тех, кто может, это никому не нужно ;-)

/cc @andrewblond

Можно делать копию во временную папку для каждого бандла (по названию, например), затем там делать сборку, туда складывать все, а затем копировать оттуда в итоговую папку только нужное (явно указанные таргеты).

Да, можно =) В ENB с этим никаких проблем не будет.

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

@apsavin, технология file-copy не будет копировать файл, если он не был изменён: https://github.com/enb-make/enb/blob/master/techs/file-copy.js#L73-L74.

Кажется, совсем не сложная задача. Почему этого до сих пор никто не сделал?))

Нам не нужно. Подобное хочется только при деплое что решается одной строчкой в деплой скрипте

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

@apsavin Я вот тоже удивляюсь. Но с другой стороны — это боль писать конфиги под enb/bem-tools. Не знаю почему, но что уж греха таить.

@zxqfox дело привычки. Мне писать конфиги под bem-tools - одно удовольствие, я просто помню, что там и куда. На enb не писал ничего, так как не видел смысла слезать с любимого сборщика - но вот, видимо, время пришло попробовать.

@apsavin Само собой, когда помнишь, то норм. Удовольствие — о вкусах не спорят, как говорится...

Но:

1. Мешает это, в большинстве случаев, тем, кто изучает продукт/методологию;
2. Учатся, обычно, по bem-tools, а в нем я вообще сомневаюсь, что это возможно;
3. В enb это тоже не две строчки, но тем, кто уже дошел до enb, чаще всего либо нормально и так, либо они не считают нужным выкладывать эти строчки куда-то еще, потому что считают уже их очевидными.

Вот и несходятся те, кого любят, с теми, кто любит.

Мешает это, как минимум, всем, кто использует IDE от Jetbrains) Вообще, мой вопрос выше про "почему никто не сделал" был риторическим.

А при чём тут IDE расскажите? :)

IDE индексирует генерирующиеся файлы.

@apsavin IDE от Jetbrains умеют вычитать из индекса по маске ;)

@tadatuta Все равно открывать нужный файл неудобно, когда их 100500 в папке)

@apsavin из моего опыта: когда верстаешь статику, таб с bemjson.js все время открыт в редакторе — он все время нужен, а когда разрабатываешь динамику, то ходить в бандлы вообще нет необходимости — кладешь один раз bemdecl.js с одним единственным блоком server, а все остальные блоки подхватываются по зависимостям.

@tadatuta по-разному бывает) Обсуждать кому как удобно, наверное, нет большого смысла. Понятно, что можно по-разному изворачиваться, в конце концов, работают ведь все, включая меня. Я в любом случае попробую сделать так, как мне удобно, с помощью ENB. Да и с bem-tools, кажется, слезать надо - официальная поддержка ведь к ENB перешла.

@tadatuta +1

На проекте сделал такое решение: 1) Слои *.bundles генерятся по конкретной папке с .blocks которая содержит блоки страниц и блоки с deps.js для сборки js либ 2) Генерируются они в отдельном папке, и сборка конечного продукта происходит в эти папки.

Такой путь народ удовлетворил. Все папки со слоями *.bundles исключаются из индекса IDE.

@tadatuta @andrewblond

Есть ли подробная схема или описание алгоритма сборки BEM-проекта? Например: 1) Прочитать в заданном уровне, напимер desktop.bundles файл, например product.bemdecl.js read desktop.bundles//product/product.bemdecl.js 2) Для каждого блока, задекларированного в desktop.bundles//product/product.bemdecl.js прочитать файл deps.js и ....

Буду очень благодарен, если поможете найти/составить алгоритм :)

@alexbaumgertner см. https://github.com/enb-bem/enb-bem-techs#Документация