@alexanderbondarchuk Привет!

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

Я бы предложил поступить так: разобраться с «основной» частью на основе node.js. Исхожу из того, что JS для любого фронтэнд-разработчика знаком и освоение ноды и npm не будет слишком сложным благодаря большому количество туториалов всех видов.

Для общего понимания того, как работает сборка, я бы порекомендовал методологическое описание https://ru.bem.info/method/build/ + https://ru.bem.info/method/declarations/ — здесь буквально на 10 минут чтения и объясняются именно принципы, без какой-то привязке к конкретным сборщика и инструментам.

А следующим шагом посмотреть вот это видео: https://www.youtube.com/watch?v=-un-YYgU6Pg Там (как мне кажется) сборка объяснена более-менее внятно.

И уже после такого знакомства погружаться в связку с PHP.

@tadatuta спасибо за ссылки, ознакомлюсь на неделе.

@alexanderbondarchuk Если по сути, то сборщик не нашел файл desktop.bundles/firstpage/firstpage.bemjson.js а именно в нем должна быть описана структура страницы.

@tadatuta, эти вещи действительно уже читал, но они начали вылетать из головы, когда начал пытаться адаптировать прочитанное для PHP. Повторение информации оказалось полезным для меня.

Видео пока не смотрел, но по прочитанному очень абстрактно и без конкретики описаны несколько вещей:

1. В результате сборки можно получить разные финальные наборы файлов - далее говорится что наборы файлов могут быть как для отдельной страницы, так для куска страницы или для шапки и подвала. БЭМ сам определяет что шапка, что кусок, а что целиковая страница? Так же, если не ошибаюсь, в пачки попадают и ненужные на сервере файлы, промежуточные - но об этом ничего тут не сказано. Или я ошибаюсь?
2. При сборке в проект могут быть включены все БЭМ-сущности с файловой системы/только необходимые для построения страницы БЭМ-сущности - и далее идёт уточнение, что чтобы включать только нужное, надо использовать декларации, зависимости и уровни переопределения. В примерах файловой системы бэм-проекта ДО сборки файл decl уже лежит в пачке, однако если читать материал про зависимости - там сказано, что кроме ручной подготовки такого файла есть ещё 2 автоматических способа, например При сборке страницы декларация формируется автоматически на основании данных из БЭМ-дерева. При этом вроде используется инструмент html2bemjson. Что-то здесь совсем не понятно - с одной стороны нам обязательно надо готовить заранее decl файл, с другой нам говорят что при сборке (enb make, верно?) этот decl файл сам соберётся.
3. Очень заинтересовала алгебра деклараций, но почему-то нет практического примера с ними. В информации есть прям раздел "Алгебра деклараций", где говорятся вроде бы очевидные для копипаста вещи, но читая начинает казаться что видимо не всё так просто и не так понимаю. Вот меня заинтересовал случай с пересечением деклараций. В примере разобраны 2 декларации создающие 3 декларацию. Это понимать просто как подход к формированию структуры своего проекта или всё-таки тут что-то связанное с процессом сборки и зависимостью от деклараций? Если со сборкой, то хотелось бы понять пример деклараций с пересечением, когда у меня есть index.php страница, а в её тело по POST заголовкам гружу страницы main или contacts. Header и Footer у меня в index, body в main и contacts

Кстати, есть ошибка на странице https://ru.bem.info/method/build/ не работают якоря для ссылок

перечислить блоки, элементы и модификаторы, участвующие в построении страницы указать зависимости используемых БЭМ-сущностей

БЭМ сам определяет что шапка, что кусок, а что целиковая страница?

Нет, с точки зрения сборки это просто не важно. Управляется это списком сущностей, которые попали в декларацию.

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

Да, но не так-то просто однозначно понять, какие файлы нужны, а какие нет, поэтому чистка лишнего отдается на откуп разработчику. Должно хватить однострочника типа rm *bundles/*/*.{decl.js,deps.js} с необходимыми расширениями.

с одной стороны нам обязательно надо готовить заранее decl файл, с другой нам говорят что при сборке (enb make, верно?) этот decl файл сам соберётся.

Не совсем так. Список сущностей, которые должны попасть в бандл при сборке, обязан быть предоставлен в каком-либо виде: можно написать его руками в виде decl-а, можно написать руками BEMJSON или любой другой формат, из которого этот decl можно сгенерировать. Но важно понимать, что при динамической генерации страницы дерева заранее нет и распространенная практика выглядит так: в decl указывается один корневой блок root, а все остальные зависимости строятся по блочным deps.js-файлам.

Очень заинтересовала алгебра деклараций, но почему-то нет практического примера с ними

Мы сознательно в разделе Методология не приводим никаких готовых примеров. Работа с декларациями реализована, например, в ENB: https://ru.bem.info/tools/bem/enb-bem-techs/api/#mergebemdecl (и ниже по тексту).

Кстати, есть ошибка на странице https://ru.bem.info/method/build/ не работают якоря для ссылок

перечислить блоки, элементы и модификаторы, участвующие в построении страницы указать зависимости используемых БЭМ-сущностей

@vithar посмотришь на якоря?

Да

https://github.com/bem/bem-method/commit/eed334ed8a50fffed1e2c5ad7089da1d74bf0193

https://github.com/bem/bem-method/commit/cbd6a4a1a809264e1d5652d66f9f381c3640d419

@tadatuta Владимир, видео посмотрел. Всё понятно, очень жаль только что про decl и deps пару слов сказано.

Вы пишете

при динамической генерации страницы дерева заранее нет и распространенная практика выглядит так: в decl указывается один корневой блок root, а все остальные зависимости строятся по блочным deps.js-файлам

Допустим я придумал себе блок hardlabel, который хочу подключить на страницу. Мои действия

1. Создаю hardlabel.css, hardlabel.js (ставит модификатор по клику) и кладу в common.blocks/hardlabel
2. В bundles у меня есть страница index/, куда кладу файл index.decl.js с содержимым

exports.blocks = [
    { name: 'hardlabel' }
];

Т.е. при сборке enb make поймёт, что я хочу подтянуть css и js по блоку hardlabel? В данном случае hardlabel и есть корневой блок о котором вы говорите? Или под корневым имеется в виду i-bem блок?

Не совсем понял роль deps... Т.е. кроме того что мы в decl сказали подтянуть нам css и js файлы блока hardlabel, нам надо в hardlabel.deps.js указать что-то вроде этого?

{
    tech: 'js',
    mustDeps: [
        {
            block: 'hardlabel',
            tech: 'bemhtml'
        }
    ]
}

Т.е. при сборке enb make поймёт, что я хочу подтянуть css и js по блоку hardlabel?

Да.

В данном случае hardlabel и есть корневой блок о котором вы говорите? Или под корневым имеется в виду i-bem блок?

Формулировка вопроса позволяет разночтения, поэтому отвечаю развернуто. Заодно и на следующий вопрос отвечу. «Корневой» — в терминах графа зависимостей, аналог точки входа для Webpack. Например, таким блоком может быть page. А дальше у блока page в файле deps.js могут оказаться header, main, sidebar и footer. У header, в свою очередь, будет зависимость от logo. У sidebar — от link. У footer — от copyright. И так далее.

В результате сборщик принимает на вход декл с page и достраивает весь граф зависимостей с помощью зависимостей, указанных в блочных deps.js файлах.

Пример в коде: https://github.com/tadatuta/bem-express/tree/master/common.blocks (см. root и далее по deps.js в common.blocks).

Вместо этого, конечно, можно написать весь список зависимостей в декле, но схема с блочными deps.js-файлами лучше тем, что каждый блок сам отвечает за свои зависимости. Т.о., например, при удалении какого-либо блока, автоматически исключаются все его зависимости.

@tadatuta Владимир, доброго времени суток. Нечто невероятно функциональное удалось сотворить, значит инструкции по теории + видео оказались полезными и думаю в будущем могут помочь не только мне.

Следующим шагом мне бы хотелось реализовать то же самое, но в связке с PHP. 1) Какую информацию почитать для этого? 2) В чём разница между bh, bemhtml, bemjson и что из этого предпочтительнее использовать при разработке с помощью PHP? 3) Правильно ли я понял про корневые элементы, что под корневым имеется в виду самый дочерний блок (который мы и указываем в decl), а с помощью deps лежащих в *.blocks от этого дочернего блока строятся все остальные связи, которые в целом могут не беспокоить разработчика?

Следующим шагом мне бы хотелось реализовать то же самое, но в связке с PHP. 1) Какую информацию почитать для этого?

Зависит от схемы, по которой хочется делать эту связку: какие требования, чего хочется достить в результате?

2) В чём разница между bh, bemhtml, bemjson и что из этого предпочтительнее использовать при разработке с помощью PHP?

BEMJSON — это формат описания дерева страницы в терминах блоков. Было

<div class="b1">
    <div class="b1__elem1"></div>
</div>

Стало

{
    block: 'b1',
    content: { elem: 'elem1' }
}

Подробнее см. https://ru.bem.info/technology/bemjson/

А BEMHTML и BH — это два шаблонизатора, которые на вход принимают BEMJSON и возвращают HTML. Разница в синтаксисе и некоторых тонкостях в реализации.

Если говорить про PHP, то существует порт BH на PHP — https://github.com/bem/bh-php + в комплекте есть шаблоны для блоков из библиотек bem-core и bem-components.

3) Правильно ли я понял про корневые элементы, что под корневым имеется в виду самый дочерний блок (который мы и указываем в decl), а с помощью deps лежащих в *.blocks от этого дочернего блока строятся все остальные связи, которые в целом могут не беспокоить разработчика?

Да, все так.

@tadatuta

Зависит от схемы, по которой хочется делать эту связку: какие требования, чего хочется достить в результате?

Для начала хотелось бы понять что меняется в процессе сборки проекта enb make, когда в нём появляются php файлы, кладутся ли они в другие директории или по прежнему в bundles?

Про bh-php знаю, устанавливал и немного баловался. Не понятно может ли enb make работать с bh-php?

Если верно понимаю, то раз bh-php это шаблонизатор то код страницы по прежнему можно писать в отдельном bemjson файле, даже если я хочу работать с проектом на php. Можно ли в php использовать bemhtml и что между ним и bh-php будет удобнее в работе?

Высока вероятность, что bemhtml будет более современной и актуальной, чем bh-php, потому что в первую очередь методология БЭМ дружит с javascript и node.js, а потом уже делаются доработки для других языков?

Про bh-php знаю, устанавливал и немного баловался. Не понятно может ли enb make работать с bh-php?

enb-bh-php собирает bh.php точно так же, как и enb-bh собирает bh. После сборки надо будет подключать себе файлы с шаблонами и делать $bh->apply(['block' => 'page']).

Если верно понимаю, то раз bh-php это шаблонизатор то код страницы по прежнему можно писать в отдельном bemjson файле, даже если я хочу работать с проектом на php.

Всё так. Можно, но не обязательно нужно. В любом случае, нужна будет какая-то точка отсчета для сборки бандлов — это либо bemjson (из которого можно получить список используемых бэм-сущностей) либо bemdecl (голая декларация из кусков бэм-сущностей).

Можно ли в php использовать bemhtml и что между ним и bh-php будет удобнее в работе?

Технически, можно, но это не эффективно, поскольку bemhtml написан на js, и запускаться в php может только через адаптеры (например, биндинги v8). Но если есть возможность поднять nodejs-прокси, который будет делать ровно рендеринг html из bemjson используя bemhtml, то лучше сделать именно так, а из php отдавать json_encode(bemjson-структура).

Высока вероятность, что bemhtml будет более современной и актуальной, чем bh-php

Тут даже вероятность не нужно считать — она ровно 100. Но запускать bemhtml из php практически невозможно и поэтому есть bh-php (кроме того, он появился еще когда у bemhtml были не самые лучшие времена, но это другая история).

методология БЭМ дружит с javascript и node.js, а потом уже делаются доработки для других языков?

Сама методология в первую очередь методология, поэтому ей без разницы с кем дружить и она просто ни с кем не ссорится. Но есть браузерные разработчики, которые интересуются BEM, и знают они именно JS, поскольку он используется в браузере — это и есть главная причина, почему 99.99% всего написано на JS.

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

Для начала хотелось бы понять что меняется в процессе сборки проекта enb make, когда в нём появляются php файлы, кладутся ли они в другие директории или по прежнему в bundles?

По прежнему в .bundles, просто собираются немножко иначе — обертка в другом синтаксисе, и <?php в начало добавляется ;-).

@tadatuta @zxqfox Всем привет.

Такс, если речь пошла про enb-bh-php, то логично это это ещё какая-то технология, которая должна быть установлена. Я не знал как проверить есть она или нет в моём стандартном project-stub, поэтому просто выполнил согласно инструкции команду npm install --save-dev enb-bh-php, выдало следующее

bem-project-stub@1.5.0 /home/alexander/DeveloperWorkspace/WEB_BEM_PHP_Yandex
└── enb-bh-php@0.1.4

Честно говоря даже после выполнения этой команды не удалось понять что и куда добавилось. Т.е. сделав это я могу быть уверен, что все инструменты для сборки PHP проектов у меня есть?

Едем дальше. Про подключение файлов с шаблонами вообще ничего не понял. Вот есть у меня страничка htmlpage, в ней лежат htmlpage.bemjson.js и htmlpage.decl.js, которые после команды enb make "делают хорошо". Шаблоном в данном случае является, если не ошибаюсь htmlpage.bemjson.js. Не совсем понял как связать этот шаблон и команду $bh->apply(['block' => 'page']) - наверное всё-таки в скобках этой команды должно попадать полное содержимое из файла htmlpage.bemjson.js?

После сборки надо будет подключать себе файлы с шаблонами и делать $bh->apply(['block' => 'page']).

Для успешной сборки html+css+javascript мне в пачке htmlpage хватило двух файлов htmlpage.bemjson.js и htmlpage.decl.js. Если верно понимаю, для PHP будет нужно что-то ещё. В какую сторону смотреть, если для начала я просто хочу реализовать абсолютно то же самое что реализовал выше, но с помощью PHP?

после выполнения этой команды не удалось понять что и куда добавилось. Т.е. сделав это я могу быть уверен, что все инструменты для сборки PHP проектов у меня есть?

Тут требуются общие базовые знания работы с node.js. Мы их не осилить давать в нашей документации, но есть огромное количество обучающих материалов именно про ноду и npm. Могу порекомендовать скринкасты http://learn.javascript.ru/screencast/nodejs

Шаблоном в данном случае является, если не ошибаюсь htmlpage.bemjson.js

Как я и писал выше, BEMJSON — это описание страницы в терминах блоков. А за то, как это описание превратится в HTML отвечают шаблоны. Т.е. htmlpage.bemjson.js следует воспринимать скорее как данные (правда уже view-ориентированные).

Шаблоны по аналогии с тем, как CSS стили применяются к узлам дерева HTML, применяются к узлам дерева BEMJSON и задают правила их рендеринга. И, как и с CSS, существуются правила по умолчанию, которые отрендерят любой узел в div с необходимым классом, даже если вообще не писать никаких шаблонов. Сами шаблоны (снова-таки по аналогии с CSS) лежат рядом с каждым блоком в отдельном файле и представляют из себя утверждения вида «найди в дереве узел, отвечающий селектору и пусть тег у подходящих узлов будет span».

как связать этот шаблон и команду $bh->apply(['block' => 'page']) - наверное всё-таки в скобках этой команды должно попадать полное содержимое из файла htmlpage.bemjson.js?

После сборки в $bh будет объект с методом apply, содержащий знание про все шаблоны нужного бандла. Аргументом apply как раз и должен быть BEMJSON: $bh->apply($bemjsonFromHtmlPage).

Для успешной сборки html+css+javascript мне в пачке htmlpage хватило двух файлов htmlpage.bemjson.js и htmlpage.decl.js.

Если стартовал с project-stub, то должно быть достаточно одного htmlpage.bemjson.js, декл генерируется на его основе.

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

Смотреть в сторону enb-bh-php. Это пакет, который соберет шаблоны в бандл вида desktop.bundles/pagename/pagename.bh.php. Этот файл предоставит объект $bh с методом apply(). Остается передать ему содержимое desktop.bundles/pagename/pagename.bemjson.js, чтобы на выходе получить HTML-строку, которую можно сохранить на диск или вернуть пользователю в ответ на запрос — зависит от решаемой задачи.

Кроме того, если есть желание использовать блоки из библиотек bem-core и bem-components, есть смысл подключить в сборку библиотеки с PHP-шаблонами для них:

• https://github.com/bem/bem-core-php
• https://github.com/bem/bem-components-php

@zxqfox

enb-bh-php собирает bh.php точно так же, как и enb-bh собирает bh. После сборки надо будет подключать себе файлы с шаблонами и делать $bh->apply(['block' => 'page']).

@tadatuta

После сборки в $bh будет объект с методом apply, содержащий знание про все шаблоны нужного бандла.

Всем пример. У меня htmlpage.bh.php НЕ появился после enb make. В директории htmlpage лежал только htmlpage.bemjson.js. Собрался html, css, javascript. Но ничего для PHP нет. Пакет enb-bh-php установлен.

необходимо добавить знание про сборку bh.php в .enb/make.js. Про конфигурацию ENB см. https://ru.bem.info/tools/bem/enb-bem/

@tadatuta спасибо за ссылку, так же весьма оказалось полезным, но не удалось найтии информацию про знание для php. Смотрел тут, тут и тут. По информации с последней страницы даже выполнил npm install --save-dev enb-bh, но после enb make страницы для php не появились. Как добавить знание про PHP в make.js, как оно выглядит так и не понял.

Так же почитал общую информацию про enb, в частности заинтересовала информация на странице Сборка страницы Ранее у меня возникал вопрос об обязательности decl.js файла, ответ был, но я его не понял. Если верно понял информацию с этой страницы, то в decl.js файле нет необходимости, если в пачке есть *.bemjson.js файл, в котором описаны все необходимые блоки. Если же такого нет, то decl.js файл будет обязательным, верно? К сожалению пока не догадываюсь для каких задач это надо, но предполагаю что такая возможность реализована для удобства использования node.js и написания серверного кода на javascript... На странице нигде не сказано что произойдёт, если разместить и bemjson.js и decl.js (там только про deps рассказано) - что будет в приоритете. Провёл эксперимент, в decl.js указал блок, которого нет в bemjson.js - в результате в min.js и min.css он не попал всё равно. Считать этот результат закономерным или это случайностью? Далее есть такая строчка

NB-конфиг (.enb/make.js) будет выглядить следующим образом

У меня конфиг в project-stub существенно отличается, бросается в глаза browser-js против js на странице про процесс сборки. Где можно посмотреть какие технологии для enb make.js устаревшие, какие в себя включают подтехнологии и т.д.? На первый взгляд по конфигу из project-stub рулит js и css borschik...

К сожалению пока не догадываюсь для каких задач это надо

Все просто. Сборщику нужно знать ЧТО конкретно собрать предстоит. Эти знания хранятся в bemdecl.js файлах.

@kompolom вопрос был не об этом

@alexanderbondarchuk А в чем тогда?

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

1. Для ENB совершенно все рано, что собирать — css, js или php-файлы. Это все равно просто текстовые файлы, которые нужно найти по декларации на заданных уровнях переопределения (читай «в указанных папках») и собрать в один или несколько бандлов.
2. За то, что именно кроется за словом «собрать», отвечает уже конкретный модуль сборки (aka технология). В простом случае, как, скажем, для CSS, достаточно просто генерировать @import с путем до каждого нужного файла. Для PHP это могут быть include. Более сложные случаи могут включать дополнительные действия вроде компиляции, минимизации, обфускации и т.п.

Документация на тему: https://github.com/enb/enb/#Как-написать-свою-технологию Ну и исходники существующих технологий должны быть более-менее понятные.

Ранее у меня возникал вопрос об обязательности decl.js файла, ответ был, но я его не понял. Если верно понял информацию с этой страницы, то в decl.js файле нет необходимости, если в пачке есть *.bemjson.js файл, в котором описаны все необходимые блоки. Если же такого нет, то decl.js файл будет обязательным, верно?

decl.js всегда необходим для сборки, но если есть bemjson.js, его можно сгенерировать автоматически. За это отвечает вот этот шаг сборки.

Соответственно, если этот шаг в конфиге присутствует, decl.js при пересборке будет перетираться автосгенерированным.

пока не догадываюсь для каких задач это надо

decl.js стоит писать руками, когда bemjson.js генерируется в рантайме (в зависимости от роута, в результате похода в БД и т.д.). Т.е. мы заранее собираем все нужные бандлы для всех возможных сущностей, а HTML создаем в ответ на запрос пользователя, а не на этапе сборки.

У меня конфиг в project-stub существенно отличается, бросается в глаза browser-js против js на странице про процесс сборки. Где можно посмотреть какие технологии для enb make.js устаревшие, какие в себя включают подтехнологии и т.д.? На первый взгляд по конфигу из project-stub рулит js и css borschik...

В project-stub используются актуальные версии актуальных технологий. Кроме того, у технологий для сборки более-менее неплохая документация, из нее должно быть понятно, какие и для чего стоит использовать.

Ну и, наконец, конкретно про сборку bh.php. Кроме собственно установки пакета, необходимо добавить его вызов в .enb/make.js. Как это сделать написано в ридми к пакету: https://www.npmjs.com/package/enb-bh-php

В качестве примера можно попробовать посмотреть на https://github.com/bem/project-stub/blob/php-bem-bh/.enb/make.js#L68-L74

@tadatuta приветствую. Создать файл удалось, но были проблемы и есть вопросы.

Проблемы 1.Может быть неправильно читаю инструкцию к пакету, но указанная там команда мне не помогла. Добавил её в самый конец, но после enb make файлы bh.php не появились:

nodeConfig.addTargets([/* '?.bemtree.js', */ '?.html', '?.min.css', '?.min.js']); nodeConfig.addTech(require('enb-bh-php').bhPhp);

2.Решил добавить информацию из другого предоставленного примера, сборщик начал ругаться на конфликт технологий.

Error: Concurrent techs for target: htmlpage.html, techs: "bemjson-to-html" vs "bemjson-to-html"

Закомментил такую строку

//bond bemjsonToHtml: require('enb-bemxjst/techs/bemjson-to-html')

Появилась другая ошибка

TypeError: TechClass is not a function

Нелогично, но решил поискать всё что связано с bemjsonToHtml, решил закоментить следующее

//bond [techs.bemjsonToHtml],

Ошибка изменилась

Error: Concurrent techs for target: htmlpage.bh.php, techs: "bh.php" vs "bh.php"

Закоментил добавленную с помощью первой инструкции строку

//bond nodeConfig.addTech(require('enb-bh-php').bhPhp);

После сборки файлы bh.php появились, но смущает инфо сообщение

[deprecate] [/home/alexander/DeveloperWorkspace/WEB_BEM_PHP_Yandex/node_modules/enb-bh-php/techs/bemjson-to-html.js(20.21)] require-or-eval is deprecated. Please use enb-require-or-eval.

Вопросы 1.Хоть сборка и прошла, но файл htmlpage.bh.php выглядит так,

<?php
require_once __DIR__ . "/../../vendor/bem/bh/index.php";
$bh = new \BEM\BH();
$bh->setOptions(json_decode("{\"jsAttrName\":\"data-bem\",\"jsAttrScheme\":\"json\"}", 1));
return $bh;

а htmlpage.bemjson.js для него так

module.exports = {
    block : 'page',
    title : 'Title of the page',
    favicon : '/favicon.ico',
    head : [
        { elem : 'meta', attrs : { name : 'description', content : '' } },
        { elem : 'meta', attrs : { name : 'viewport', content : 'width=device-width, initial-scale=1' } },
        { elem : 'css', url : 'htmlpage.min.css' }
    ],
    scripts: [{ elem : 'js', url : 'htmlpage.min.js' }],
    mods : { theme : 'islands' },
    content : [
        {
            block : 'hardlabel',
            js: true,
            content : [
                'Мой первый успешный блок'
            ]
        }
    ]
};

Что-то они совсем не похожи по моему... Или я не правильно понял смысл сборки bh.php?

2.Хоть всё что связано с html отключил, такие файлы всё равно появляются в сборке, но в какой-то сокращённой вариации. Зачем? <div class="page page_theme_islands"><div class="hardlabel i-bem" data-bem="{&quot;hardlabel&quot;:{}}">Мой первый успешный блок</div></div>