Ответ на вопрос 2. Если поискать https://github.com/bem/project-stub/search?q=merged&type=Issues&utf8=%E2%9C%93 то можно найти зачаточную историю о добавлении и удалении...

Протестировал работает, немного поправил, смотри: https://github.com/bem/project-stub/compare/0c15a15da1ad0240d9d449f2c8cd34538d192eb5...ilyar:example-merged-enb?expand=1

@ilyar как я понимаю, получившиеся js и css файлы — это простая склейка соотв. файлов страниц (бандлов) — http://take.ms/ozs4J — скрин для двух страниц. гарантировать очередность в такой ситуации будет непросто...

Это не простая склейка, то что на скрине скорей всего ошибка.

смотри добавил пару страниц и блоков https://github.com/ilyar/project-stub/commit/f98604c84b3b3b7e94820a432e593b219e3dabc1

index содержит b0 и b1 page1 содержит b0 и b1 и b2 ⇒ some (b2 ожидает, что до него будет блок some зависимость mustDeps) page2 содержитb0иb3`

вжих и готово https://github.com/bem/project-stub/commit/9182785ed4afa6b8d0a0ba74a1a6b010f993792e

merged-декларация:

exports.blocks = [
    {
        "name": "b0"
    },
    {
        "name": "b1"
    },
    {
        "name": "b2"
    },
    {
        "name": "b3"
    }
];

merged-зависимости:

exports.deps = [
    {
        "block": "b0"
    },
    {
        "block": "b1"
    },
    {
        "block": "some"
    },
    {
        "block": "b3"
    },
    {
        "block": "b2"
    }
];

merged-результат:

.b0 {}
.b1 {}
.some {} /* как и требовалось до b2 */
.b3 {}
.b2 {}

Bonus: script watch (LiveReload)

+    "browser-sync": "^2.18.5",
   },
    "scripts": {
+    "watch": "enb server & browser-sync start --files \"*.blocks/**/*, *.bundles/**/*.bemjson.js\" --proxy 0.0.0.0:8080",

@ilyar спасибо! п.с.: автозагрузка на винде не заводится — браузерсинк стартует только после остановки enb-сервера ))) я пока планирую использовал галп — копировать JS и CSS из merged-бандла, HTML из прочих бандлов и доп. файлы в папку сборки, в ней же и браузерсинк пускать.

Да. Стартует enb сервер, работает, в браузере на локалхосте показываются бандлы, по изменению разметки не происходит ничего, нужно обновлять страницу, чтобы увидеть. Останавливаю enb, вижу в консоли вывод браузерсинка, типа он стартовал на 3000 порту )) ну и --proxy 127.0.0.1:8080 у меня вместо нулей.

Случайно дропнул свой вопрос: "Интересно, расскажи подробнее, запускал через npm run watch?"

Уверен, что до запуска npm run watch порт свободен и enb не запущен?

оба упомянутых порта (3000 и 8080) свободны, если верить netstat enb не запущен

https://github.com/nicothin/project-stub — экспериментирую в этом репозитории.

Уверен, что меняешь прописанные в --files файлы?

Абсолюно. Но какая разница что я меняю, если в момент изменений браузерсинк еще не заупщен? )) Я ж говорю, он стартует только после остановки ENB. Словно там && написано, а не &.

Ааа... понял, наверное это особенность window. Вижу два варианта:

POSIX совместимость choco install babun -y и попробуй еще раз.

Или попробуй разбить скрипт на два (старт enb и отдельно browser-sync), а точнее для project-stub уже есть npm start запускаем и в отдельной консоле npm run bsync или просто browser-sync start --files "*.blocks/**/*, *.bundles/**/*.bemjson.js" --proxy 0.0.0.0:8080.

Еще может будет полезна тема: enb LiveReload или аналоги.

Рекомендую пробовать именно "POSIX совместимость", но нет абсолютной уверенности, что это сработает, но попробовать стоит.

Если будет работать, это может решить другие особенности windows-платформы.

Перелезать с гитбаша на бабун... Ну, не знаю...

Если есть другие способы добиться "POSIX совместимость" на windows-платформе, буду рад узнать.

В общем, не работает автообновление в винде, как не бейся. Выход только один ( и относительно паршивый): собирать все в какую-то папку (сам буду галпом пробовать) и запускать enb make на каждое изменение файлов, после чего снова копировать в папку сборки и по этому факту уже обновлять браузерсинком. Мейк у меня даже в самом простом случае — 2 сек, что в «непростом» будет — подумать страшно :(

Как вариант, попытаюсь завтра поставить таки на свою Win 10 режим разработчика и консоль убунты.

@nicothin «даже если вас съели, у вас есть два выхода» ;)

В данном случае вариантов решения гораздо больше. А заодно и способов оптимизации, чтобы ускорить сборку. Но опять-таки, чтобы мочь выбрать самый подходящий, мне хорошо бы понимать задачу целиком. Я прочитал описание из https://ru.bem.info/forum/1207/#comment-271090255, но этого все равно недостаточно, чтобы сложить полную картину.

Несколько наводящих вопросов:

• Зачем нужна именно такая структура? Какую проблему она решает по отношению к той, что предполагается из коробки? Например, если она требуется для деплоя, то к ней можно приводить один раз перед деплоем, а в процессе разработки оставить исходную.

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

• Если собираться на gulp, то финальная структура выражается с помощью gulp.dest() и может быть совершенно произвольной. Если же предпочтительна сборка на ENB, то есть технология file-copy, которая позволяет копировать файлы по произвольному пути как один из шагов сборки.

• Если желание получить описанную файловую структуру происходит от необходимости получить определенную структуру урлов, то эту задачу можно решить роутингом на уровне веб-сервера (nginx, node.js, etc.)

• browser-sync нужен именно в таком исполнении или любая реализация live reload подойдет?

• enb make занимает много времени на инициализацию, если его поднять как процессе (а-ля enb server, то каждая пересборка будет заметно быстрее.

• Если в сборке присутствуют всякие «дорогие» с точки зрения времени выполнения шаги, то можно ли часть не выполнять в процессе девелопмента или закешировать?

Это, конечно, далеко не все вопросы, которые могут помочь собрать оптимальный конфиг, так что буду рад максимальному количеству подробностей.

Впрочем, базовый универсальный вариант вотчера с лайв релоадом давно пора добавить в bem-express, думаю, сделаю это завтра, возможно, это можно будет использовать как частичный ответ.

Протестировал на windows способ watch (LiveReload), это не работает, POSIX совместимость либо не достижима для windows, либо я не умею готовить.

Но думаю есть решение concurrently:

npm install -g concurrently
npm install -g browser-sync --msvs_version=2013 # специально для пользователей windows-платформы, но возможно и без этого флага будет работать 
concurrently "enb server" "browser-sync start --files \"*.blocks/**/*, *.bundles/**/*.bemjson.js\" --proxy 0.0.0.0:8080"

Полностью протестировать данное решение не получилось, возможно это проблема виртуалки на которой все делал.

В общем думаю будет работать.

@ilyar перевел винду в режим разработчика, поставил подсистему убунту и использовал убунтовский баш для вызова npm run watch (который "watch": "enb server & browser-sync start --files \"*.blocks/**/*, *.bundles/**/*.bemjson.js\" --proxy 0.0.0.0:8080"):

nicothin@NICWIN10 /mnt/d/projects/project-stub
 % npm run watch

> bem-project-stub@2.0.0 watch /mnt/d/projects/project-stub
> enb server & browser-sync start --files "*.blocks/**/*, *.bundles/**/*.bemjson.js" --proxy 0.0.0.0:8080

/mnt/d/projects/project-stub/node_modules/dev-ip/lib/dev-ip.js:21
    var networkInterfaces = require("os").networkInterfaces();
                                          ^

Error: EINVAL: invalid argument, uv_interface_addresses
    at Error (native)
    at getIp (/mnt/d/projects/project-stub/node_modules/dev-ip/lib/dev-ip.js:21:43)
    at Object.<anonymous> (/mnt/d/projects/project-stub/node_modules/browser-sync/lib/utils.js:4:38)
    at Module._compile (module.js:570:32)
    at Object.Module._extensions..js (module.js:579:10)
    at Module.load (module.js:487:32)
    at tryModuleLoad (module.js:446:12)
    at Function.Module._load (module.js:438:3)
    at Module.require (module.js:497:17)
    at require (internal/module.js:20:19)

npm ERR! Linux 3.4.0+
npm ERR! argv "/usr/bin/nodejs" "/usr/bin/npm" "run" "watch"
npm ERR! node v6.9.4
npm ERR! npm  v3.10.10
npm ERR! code ELIFECYCLE
npm ERR! bem-project-stub@2.0.0 watch: `enb server & browser-sync start --files "*.blocks/**/*, *.bundles/**/*.bemjson.js" --proxy 0.0.0.0:8080`
npm ERR! Exit status 1

То есть, по крайней мере, в виндовской убунте это тоже не работает. Сейчас попробую второй предложенный вами способ.

@ilyar предпочитаю иметь зависимости внутри проекта :)

npm i -D browser-sync concurrently

Для винды пришлось немного поменять команду. Итого в package.json:

"watch": "concurrently \"enb server\" \"browser-sync start --files '*.blocks/**/*.css, *.bundles/**/*.bemjson.js' --proxy 127.0.0.1:8080 --no-inject-changes\" -k",

Браузерсинк пытается инжектить стили, пришлось добавить --no-inject-changes — автоперезагрузка при изменении стилей :( (ну, хоть не руками)

Еще перспективный вариант это docker Docker контейнер для проектов на БЭМ от @nejtr0n

Супер, вжих и готово project-stub внутри.

@tadatuta давайте в том же топике продолжим, чтобы темы не смешивать. Отвечу там на вопросы.