// @andrewblond

@Guria Все, что я могу сказать — это то, что технологии для сборки лежат тут, а те технологии, которые по документации должны быть рядом, а их нет, уехали в https://github.com/enb-bem/enb-bem-techs/

@zxqfox Леша, тебе удалось завести bembundle? Поделишься достижениями?

@Guria @tadatuta Не очень удалось. Что-то собирается, но не то, что хочется. Логика сборки не ясна до конца — по мне было бы логичнее создать отдельный уровень для бембандлов, но нет, там работает иначе.

Отписывал в https://ru.bem.info/forum/issues/314/ ;-)

https://github.com/enb-make/enb-bembundle

@zxqfox если я правильно понимаю (не факт, т.к. сам не использовал), то логика там такая: собираем декларацию «любым удобным способом», по которой затем строим js-бандл, включающий сразу css+js+шаблоны, а при загрузке этого бандла с помощью https://ru.bem.info/libs/bem-core/v2.6.0/desktop/loader/#type_bundle он автоматически правильно аппендится на страницу.

Поэтому (если то, что я выше написал, правда) нет смысла выносить что-то на отдельный уровень.

У меня было то, что декларация должна лежать в соседнем бандле, и никак иначе. И все, что мы оттуда вырезаем, тоже явно в конфиге прописывается, получается, что постоянно надо будет ходить в конфиг. Нелогично, как-то.

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

@zxqfox я не уверен, что понял твою задачу. если расскажешь подробно, готов попробовать помочь.

@tadatuta Да задача-то была обычной — есть блок (или несколько), у меня даже вырезать ничего не надо было. ;-) Но чтобы собрать бандл — мне приходилось описывать в отдельной папке bemjson/bemdecl, и в конфиге явно натравливать:

    config.nodes('*.bembundles/*', function (nodeConfig) {
        nodeConfig.addTechs([
            [ebt.levels, { levels: getDesktops(config) }],
            [ebt.files],
            // здесь можно попробовать получить текущую ноду и путь из неё,
            // но я испугался подводных камней, и не был уверен, что это последний шаг
            [ebt.provideDeps, { node: 'desktop.bundles/mega-header' }],
            /* ... */
            [bembundle.css],
            [bembundle.js],
            [bembundle.page]
        ]);

        nodeConfig.addTargets([
            '?.js'
        ]);
    });

Но чтобы собрать бандл — мне приходилось описывать в отдельной папке bemjson/bemdecl

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

Например, на основе bemdecl из desktop.bembundles/*. Передавать папку бандла как параметр для сборки — как-то не очень. Я не вижу смысла смешивать бандлы обычных страниц (desktop.pages/*), которые можно посмотреть, потому что там есть bemjson, и бандлы для динамики, которые посмотреть нельзя, потому что они всегда более полные.

Если представить эту папку с бандлами как уровень с блоками, то там могут быть:

• merged бандл из всех используемых в *.pages/*;
• dist бандл из всех доступных блоков на локальных уровнях;
• какой-нибудь common, в состав которого входят блоки с наибольшим числом вхождений, или как-то еще;
• другие бандлы, типа js-бандлов — например, собранные для каждой страницы, или каких-то страниц (наборы можно описать в конфиге) из их bemdecl/bemjson, и с вырезанием из них common.

И js-бандлы отличаются от merged/dist/common, они как бы next-level. Если первые удобнее описывать исходя из каких-то уровней, например, из бандлов *.pages, и это можно сделать руками, то js-бандлы удобнее собирать из заготовленных common/dist, и в конфиге перечислять их не очень удобно — конфиг разрастается, а смысла мало. Разве что, как config.nodes('*.bembundles/*',, и с передачей туда каких-то технологий скопом, которые что-то знают про common/dist/merged/etc, и умеют читать из настроек этих бандлов какие доп. блоки, которые могут быть им нужны (т.е. какой-то bemdecl, и нечто, описывающее noDeps для сборных бандлов).

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

Конфиг в этом случае будет примерно такой.

config.nodes('*.bembundles/*', function (nodeConfig) {
    nodeConfig.addTechs([
        // исходники блоков, для тонкой работы с зависимостями и 
        [ebt.levels, { levels: getDesktops(config) }], 
        [ebt.files], // хаки для enb
        // указываем, что использовать в качестве уровней для бандлов
        [bembundle.levels, { levels: ['*.bundles/*', 'merged.bundles/*'] }],
        // на вход технологии из бандла (в т.ч. что куда резолвим),
        // бандлов bembundle.levels (из чего выбираем)
        // на выходе — итоговый deps для текущего бандла
        [bembundle.someDepsResolver],
        // дальше как обычно — берем enb-bem-techs.levels, читаем все нужное
        // клеим, заворачиваем как надо для js-bundle
        [bembundle.css], // заворачивалки
        [bembundle.js],
        [bembundle.page]
    ]);

    nodeConfig.addTargets([
        '?.js'
    ]);
});

Т.е. мне хочется чуть больше гибкости на уровне бандлов, хочется кроме bemdecl что-то вроде deps для бандлов из бандлов, чтобы я там мог noBundleDeps указать, например.

Merged бандл, технически, тоже можно будет из этого собирать вполне вменяемо — указываем что брать за исходный уровень, собираем оттуда bemdecl, склеиваем их (по умному), собираем сам бандл. Главное — как можно меньше магии.

если я тебя правильно услышал, то

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

верно?

Плюс-минус да, если enb-bembundle 100% работает. Я так и не смог его проверить — не осилил конфиги и решил не рисковать, нужно было срочно.

// @andrewblond

Я понял.

/cc @blond