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

Другой вопрос — точно ли нужно такое количество разных бандлов? Не будет ли достаточно по одному на каждое сочетание платформы/подраздела?

Ведь наверняка же у всех бандлов условного desktop/public будет общая шапка, общая навигация и общий подвал + одинаковые контролы. Поэтому зачастую будет выгоднее собрать все страницы в общий бандл и закешировать.

Правда, этот аргумент не применим к технике, когда бандлы — это не страницы, а догружаемая в рантайме функциональность какого-нибудь SPA-сервиса.

@tadatuta у нас получается вот такая штука по надобности

• admin ( только desktop ) - тут админка для управления магазином многие блоки будут сильно отличатся, что то будет переиспользоваться
• shop ( тут и mobile, desktop, tablet ) - тут клиентская часть магазина
• account ( так же как и shop и mobile, desktop, tablet ) - тут профиль пользователя

@tadatuta а ну и дизайн admin части будет сильно отличаться от shop, account

@uradvd85 я про то, что сделать по одному бандлу на каждый тип admin/shop/account * платформу. Тогда внутри каждой платформы будет всего по 3 бандла, а значит дополнительно группировать не будет смысла.

@kompolom Поддержу Володю про целесообразность такого разделения. Если действительно нужно разбивать на куски, то правильнее, было бы, считать общее автоматически, выносить в отдельный бандл, и вырезать из бандлов страниц. И на каждую платформу такое.

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

@zxqfox Я запутался пока читал что куда выносить... )) Попробуем на примерах. Есть вот так:

desktop.pages
|-- page_blog_home
|-- page_blog_post
|-- page_blog_tag
|-- page_admin_users
|-- page_admin_home
|-- page_admin_menu
итд...

При сборке все это перекладывается вот так:

merged
|-- desktop
    |-- blog
    |    |-- blog.css
    |    |-- blog.js
    |-- admin
       |--admin.css
       |--admin.js

Что хотим сделать:

desktop.pages
|-- _blog
|    |-- _home
|    |-- _post
|    |-- _tag
|-- _admin
    |-- _users
    |-- _home
    |-- _menu
итд...

А сборка чтобы также осталась как есть.

Я про такое:

desktop.pages
|-- _blog
|    |-- _common
|    |-- _home
|    |-- _post
|    |-- _tag
|-- _admin
    |-- _common
    |-- _users
    |-- _home
    |-- _menu

В _common автоматически соберутся общие куски со всех страниц (пересечение всех блоков с модификаторами). В остальные бандлы автоматически не доедут блоки, входящие в _common. И надо будет на каждой странице подключать 2 файла (_common.js, и _<page>.js).

Только я теперь не пойму, осталась ли проблема, или уже всё хорошо?

Да все было неплохо, но хочется еще лучше. Чтобы в *.pages не было каши из страниц, а разложить по папочкам как во втором варианте. Вот и вопрос в том стоит ли заморачиваться с такой структурой..

@zxqfox Кстати, вариант с common. довольно интересный. А enb умеет вычитать зависимости?

@kompolom Я вот знаю про такое: https://github.com/enb-make/enb-bembundle Но у меня с первого раза запустить его не вышло, а месяц назад вышла 2.0 ;-).

@zxqfox Я думал это для SPA приложений.

Кажется, что бандлы — они и для SPA бандлы ;-)

https://ru.bem.info/tools/bem/enb-bem-techs/api/#subtractdeps

@zxqfox с _common оч круто!!

@zxqfox бандлы то одинаковые. технологии разные. Если я правильно понял, в такой сборке можно комфортно жить без мерджей, и догружать бандлы в рантайме. Есть у кого-нить +- рабочий конфиг подсмотреть?