Я сделал страницу. К ней подключена тонна JS (это не про jQuery). Что это? Как получить необходимый минимум (только функциональность использованных блоков)?

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

То, что приезжает из коробки — это зависимости блока page (см. https://github.com/bem/bem-core/blob/v4/common.blocks/page/page.deps.js) + зависимости этих зависимостей. Их можно отстрелить с помощью noDeps, но на деле при использовании любого блока с JS-представлением (например из bem-components) они все равно потребуются. Это может казаться оверхедом пока на проекте используется пара-тройка блоков с JS, но как только блоков становится больше, размер ядра оказывается оправданным.

Как собрать результат верстки нескольких страниц в отдельную папку?

Нужно более подробное описание задачи. Результат верстки — это файлы *.{html,css,js}? Хочется просто перекладывать их из desktop.bundles/*/ в какой-то output? Какой сборщик используется?

Как получить неминимизированный HTML?

Использовать HTML beautifier. Например, для ENB есть https://www.npmjs.com/package/enb-beautify

Как получить один JS и один CSS файл для нескольких страниц?

Опять-таки зависит от сборщика. Для ENB следует использовать т.н. merged bundle.

Спасибо, вы навели меня на мысль как это собирать, попробую.

@tadatuta про п.1.: что-то я не так делаю. пишу в ./common.blocks/page/page.deps.js:

({
  noDeps : [
    { block : 'i-bem-dom' },
  ]
})

Уровень common.blocks в сборщике определен. Где я затупил?

Чтобы все отстрелить (и при условии, что в декларации нет ничего, кроме page, потребуется указать:

({
    noDeps: [
        {
            block : 'i-bem-dom',
            elems : { elem : 'init', mods : { auto : true } }
        }
    ]
})

Смысл в том, что если явно не отменять зависимости от элемента init и его модификатора, то они уже по собственным зависимостям вновь потянут i-bem-dom.

Если в декларации у блока page есть модификатор _theme_islands, то потребуется дополнительно создать _theme/page_theme_islands.deps.js и в нем отменить зависимость от

{
    block: 'ua',
    elem: 'svg'
}

Если используются какие-либо блоки из bem-components, то отменять зависимости потребуется и для каждого из них. Но это уже малоосмысленно.

PS: После избавления от зависимостей в сборку по-прежнему будут попадать модульная система ym и обвязка для клиентской шаблонизации. Если и от нее хочется избавиться, то следует выпилить соответствующие шаги сборки из .enb/make.js:

1. Удалить вот это все https://github.com/bem/project-stub/blob/master/.enb/make.js#L77-L104
2. Добавить

   [techs.browserJs, { target: '?.js' }]
   

@tadatuta так в JS -файле останется modules.define('ua', function(provide) {... но если попробовать

({
  noDeps: [
    {
      block : 'i-bem-dom',
      elems : { elem : 'init', mods : { auto : true } }
    },
    {
      block : 'ua'
    }
  ]
})

то часть содержимого секции head окажется внутри body. :( Посоветуйте как избавиться от ua в JS, пожалуйста.

Радикальный способ с полным переопределением шаблона для page логичен, но, надеюсь, есть другой способ )

Чтобы советовать что-то осмысленное, нужно знать задачу. Если задача лишь в том, чтобы не использовать i-bem.js, то эффективнее просто скопировать шаблон блока page к себе на проект, а библиотеку bem-core отключить целиком.

@tadatuta да, для меня это получается самый приемлемый вариант, благодарю.

Как собрать результат верстки нескольких страниц в отдельную папку?

Нужно более подробное описание задачи. Результат верстки — это файлы *.{html,css,js}? Хочется просто перекладывать их из desktop.bundles/*/ в какой-то output? Какой сборщик используется?

Результат — *.{html,css,js,jpg,jpeg,svg,png,gif,woff,woff2,ttf} Хочется получать файловую структуру, типа

build
  css/
    style.css      // единый стилевой, все стили всех бандлов (страниц)
    style.min.css  // то же самое, что style.css, но минимизированный
    style.css.map  // карта для style.css
  js/
    script.js // единый скрипт для всех бандлов
  img/        // картинки всех бандлов
    ...
  fonts/
    ...
  index.html
  somepage.html

И с этой структурой уже и работать, имея автообновление по изменению разметки/стилей/скриптов Насколько понимаю, это можно реализовать сборкой merged-бандла. Вообще, пришла мысль собирать все время merged-бандл и в папке, куда он собирается пускать браузерсинк, пересобирая по изменению файлов. Но даже просто собрать пока не получилось: https://ru.bem.info/forum/1208/

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

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

Хочу вести разработку в максимально приближенным к продакшену условиям. Я мало знаком с полным стеком, для меня отдаление от уровня «продакшена» (я верстальщик, для меня продакшен — состояние проекта, когда я отдаю готовую верстку на следующий этап или просто выкладываю статику на хост) является технологическим риском (по кр. мере сейчас). Не очень хочется добавлять неочевидность — менять урлы подключенных в разметке файлов (вероятно, смогу автоматизировать, если галпом собирать). Любые постобработки и неочевидности = увеличение кол-ва точек отказа.

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

Да, я уже сравнил. В самом примитивном случае полная сборка 3х бандлов (в моем случае — страниц) — 2 с, пересборка одного — 0.3 c. Полагаю, разумнее собирать только тот бандл, с которым происходит работа и в конце рабочей сессии собирать общий бандл и тестить его (лучше всего автоматом, тут gemini должен помочь, как я слышал).

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

Разве можно организовать на галпе что-то вроде enb server?

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

Отчасти. Чтобы без неочевидностей с урлами в разметке делать статичные проекты на 1-10 страниц.

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

Нужна живая перезагрузка за минимальное время. А уж как реализовывать — без разницы. С браузерсинком уже получилось без соблюдения желаемой файловой структуры.

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

Зело прочуствовал.

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

Полагаю, да.

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

Интересна реализация.

Итого, идеальный стек верстальщика с полным стеком БЭМ по моей версии

Исходник — ФС от project-stub Результат — папка сборки (build) со структурой, описанной в https://ru.bem.info/forum/1207/#comment-271090255

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

css/
    style.css      // стилевой файл показанного в браузере бандла
    style.css.map  // карта для style.css
  js/
    script.js // скрипт показанного бандла
  img/        // картинки показанного
    ...
  fonts/
    ...
  index.html // показанный сейчас в браузере бандл

По окончании рабочей сессии (на препуш, видимо) — делать общую сборку всех бандлов и тестировать.

В идеале собирать и в процессе разработки, и для тестов — галпом.

Разве можно организовать на галпе что-то вроде enb server?

так bem/project-stub/gulpfile.js вжих gulp и готово, соберет все бандлы, а все остальная магия тут http://gulpjs.com/ и https://github.com/search?utf8=%E2%9C%93&q=gulp-bem еще есть gulp: bemdecl -> bemtree + data -> bemjson + bemhtml -> html

Еще про верстальщика https://github.com/alexbaumgertner/hunter-boat + https://events.yandex.ru/lib/talks/1360/ от @alexbaumgertner

• ещё посмотрите

http://alexbaumgertner.github.io/presentation-bem-stack/

Можно посмотреть, как сделано тут:

https://github.com/gorod-mechty/gorod-mechty

Там есть и складывание в папку output, и browser-sync.

Нет раскладывания по папкам css, js, fonts, etc поскольку я считаю, что это не нужно и для продакшена всё кладётся в корень сайта.

Добавил livereload в bem-express + ENB со всеми своими модулями теперь всегда висит в памяти, это сильно экономит время на повторную пересборку: https://github.com/bem/bem-express/commit/b35696dc93c295348c4357c72c72b6aaf2587487

Дней 5 пытаюсь вникнуть в то как это работает и как организовать комфортный стартовый репозиторий. До сих пор не понял как именно оно работает. Куцая документация инструментов (или мне так кажется, ибо я верстак, а не фронтендер), долгая сборка, пляски с бубном вокруг автообновления, сборка результата с помощью .sh, DEPRECATED инструменты со ссылкой на новые, хреноводокументируемые инструменты, шаблоны одних блоков внутри других блоков...

Полный стек привлекает плюшками, но сложность организации вменяемого рабочего процесса вызывает отчаяние.

Куцая документация инструментов

Это правда, писать документацию мы любим меньше, чем код. Но стараемся по мере сил это дело исправить — все-таки контента на bem.info не так уж и мало, особенно, если посчитать людей, которые занимаются ее написанием.

долгая сборка

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

Пляски с бубном вокруг автообновления

Я так понял, что все получилось в итоге? Если нет, готов помочь разобраться окончательно. В bem-express сейчас должно работать вообще «само» из коробки.

сборка результата с помощью .sh

«Вы так говорите, как будто это что-то плохое». Ну а если серьезно, то очевидно, что любой шелл-скрипт всегда можно оформить в скрипт на gulp/grunt/you-name-it — исключительно вопрос личных предпочтений.

DEPRECATED инструменты

Это ведь говорит о том, что жизнь идет вперед и все развивается ;)

новые, хреноводокументируемые инструменты

См. первый пункт :)

Шаблоны одних блоков внутри других блоков

Я там прямо по ссылке как мог объяснил, почему это не должно быть проблемой :)

Ну и если перестать оправдываться и отвечать по делу, то должен признать, что за 5 дней самостоятельно осилить то, что у нас сложилось лет за ~5 лет итеративной разработки действительно невозможно. Это просто необходимо принять как факт — разобраться с таким количеством инструментов, библиотек и технологий и за месяц-то не факт что возможно, если рядом нет кого-то, кто уже однажды прошел этот путь.

По поводу того, что самостоятельно осилить за 5 дней полный стек невозможно, полностью согласен с Владимиром. Пару месяцев назад безвылазно изучал БЭМ месяц, ни на что не отвлекаясь: перечитал всю документацию и даже исписал целую тетрадь, т.к. для меня при написании материал усваивается легче, пересмотрел все видео доклады, анализировал готовые сайта, сделанные по БЭМ, атаковал кучей вопросов данный форум, просил популярные онлайн школы выпустить пошаговое руководство по полному стеку (например, как сделать с помощью данной технологии наиболее распространенное: landing page, корпоративный сайт и интернет-магазин). В итоге немного подзабросил все это дело, т.к. понял, что пока не дорос до такого уровня, и в данный момент параллельно с работой углубленно изучаю js, чтобы в скором вновь вернуться и наконец-то освоить данную технологию. Но усилия даром не пропали, я понял что такое модульная сборка, и что вообще можно реиспользовать какие-либо блоки. Пока что сделал свою сборку, в которой использую именование по БЭМ, похожую файловую структуру, jade, json и т.д., что в итоге позволяет легко поддерживать проект, собирать свою библиотеку блоков, да и вообще просто радоваться жизни=)) Всё это к тому, что полный стек БЭМ, может быть, действительно сложноват для "простого" верстальщика, который всю жизнь верстает одностраничники таща из-за одного события клика целую библиотеку JQuery, а потом всё это дело садит WordPress. Я ни в коем случае ни кого не хочу задеть или обидеть, но давайте профессионально развиваться и тогда любая технология, при определенных усилиях, будет нам даваться. Ведь мы привыкли прямо требовать от других, чтобы нам всё преподнесли на "блюдечке", не попытавшись хорошо вникнуть, а ведь кто-то не то что разобрался в этом, а придумал.

Да, изучить все, что связано с БЭМ, за несколько дней невозможно. Тут, кстати, встаёт вопрос о том, на что тратить своё время. Если потратить на изучение JavaScript - то у полученных знаний будет очень широкая область применения. Если месяц изучать webpack или gulp - то полученные знания можно будет применить для сборки разных проектов, созданных на разных технологиях. А если месяц изучать, скажем, enb, то полученные знания можно будет применять только для сборки БЭМ-проектов и только до тех пор, пока в Яндексе не переползут на тот же gulp.

Полный БЭМ стек - сложная штука, но, мне кажется, не многим более сложная, чем любой другой стек современного фронтенд-разработчика. На изучение всяких связок webpack+react уйдёт, пожалуй, меньше времени, но не в разы. Другой вопрос, что в последнем случае пригодиться полученное знание может в гораздо большем числе компаний - места, где оценят знания БЭМ-стека, мне кажется, можно пересчитать по пальцам.

@apsavin у меня «второй подход» к полному стеку, 5 дней как начал, уже работу предложили (с использованием полного стека). И да, понятно, что разбираться лучше «со стороны» галпа.

Всем привет. Есть ли какой-то результат по задаче, описанной @nicothin?

Сел разбираться с project stub, и столкнулся с теми же вопросами. Полазив по форуму, понял, что merged и dist бандлы не соберешь из коробки этого самого project stub'a. Ибо цель, та же - на выходе нужны человекочитаемые html n-ого кол-ва страниц с общими css и js, которые в дальнейшем уйдут в привязку к cms.

@rteamx

• Сборка merged-бандлов настроена в ветке https://github.com/bem/project-stub/tree/merged
• Человекочитаемые HTML, как и было написано в комментах выше, можно получить, если воспользоваться HTML beautifier-ом.

@tadatuta спасибо.

Не могу разобраться с HTML beautifier-ом. Поставил его и объявил в techs а дальше все, сморю на enb как баран на новые ворота:

• htmlBeautify: require('enb-beautify/techs/enb-beautify-html')
• добавил [techs.htmlBeautify], следом за [techs.bemjsonToHtml],

Сравнение make.js: https://www.diffchecker.com/FyKSdYNW

Но результата нет, что сделал не так?)

@rteamx нужен примерно вот такой дифф: https://github.com/tadatuta-studio/md8/commit/3ee5198cf3204df53f358b225351f5d7bd44706d