Алексей Ярошевич

У нас есть блок "Кнопка", у нее есть дочерний элемент "Кнопка__иконка" и модификатор "Кнопка--Иконка-Слева"(уменьшает отступ слева, чтоб иконка смотрелась лучше).
У этой кнопки есть три модификатора размера (sm,m,l). У каждого размера будет разный отступ слева при модификаторе "Кнопка--Иконка-Слева".

Легко решается через CSS Custom Properties и типографские константы
--sm, --m, --l при этом выставляют эти константы, а другие модификаторы и элементы их используют в нужных им местах.

Добавим изменение размера "Кнопка__иконка" для разных размеров кнопки (если это иконочный шрифт можно использовать font-size всей кнопки, но мы как современные используем svg иконки и размер нужно задавать вручную).

Лучше делать враппер над иконкой, чтобы не завязываться на svg или нет.
Если библиотека компонент общая — ситуации могут быть разные.
Такая структура более менее:

<Button>
  <Button__icon><Icon ... /></Button__icon>
  <Button__body>Текст на кнопке</Button__body>
</Button>

Если иконка есть — выводим `Button__icon`, если нет — не выводим. Стили вешаем на `Button__icon`.

Для кастомизации — оставляем `Button__body`, потом пригодится в кастомных `Select`.

В идеале нужна структура, чтоб видеть все связи (пример выше), для быстрого доступа к нужному свойству, но также инструмент, который умеет удалять не нужные стили по связям. Удалив элемент "Кнопка__иконка" в сборку не должны попасть модификаторы "Кнопка--Иконка-Слева" разных размеров.

Может кто то встречался с решением или рекомендациями по данному вопросу.

Звучит как сборка стилей по зависимостям из bemjson/jsx. Технически, есть возможность даже из html получить bemjson и инициировать для него сборку css/js.
Процесс будет выглядеть примерно так:

const fs = require('fs');
const miss = require('mississippi');
const html2bemjson = require('html2bemjson');
const bemjsonToDecl = require('bemjson-to-decl');
const src = require('gulp-bem-src');
const gconcat = require('gulp-concat');
const vfs = require('vinyl-fs');

src(
    ['path/to/blocks'],
    bemjsonToDecl.convert(
        html2bemjson(
            String(fs.readFileSync('path/to/your.html')))),
    'css',
    { // дополнительные настройки
        skipResolvingDependencies: false, // отключаем зависимости
        {
            'path/to/blocks': { scheme: 'nested' } // у 'path/to/blocks' схема nested 
        }
    }
).pipe(gconcat('path/to/your.css')).pipe(vfs.dest('.'))

Ну и всё

Блок должен находится на уровне переопределения. Например: app.blocks.
Удобнее блоку сделать свою папку (и все блоки хранить каждый в своей папке): app.blocks/hello-world
У блока должна быть какая-то реализация. Например, css: app.blocks/hello-world/hello-world.css

Возвращаясь к вопросу:

mkdir ./app.blocks/hello-world/ -p
touch ./app.blocks/hello-world/hello-world.css

Либо, если хотите использовать bem-tools:

npm i bem-tools
bem create level app.blocks
bem create block -l app.blocks hello-world

Текущий подход достаточно заморочен, если знаешь все прелести БЭМ.

Сейчас мы делаем:
0. Дизайнер нарисовал макет
1. Верстаем руками html: a.html
2. пишем руками стили: a.css
3. пишем руками js: a.js
4. Это все передаем бекендеру и он:
5. Доверстывает хтмл и разбивает на шаблоны, из a.html получает A.tmpl, B.tmpl, C.tmpl, ...
6. Дописывает стили в своих файлах, а часто еще и разбивает их на части: A.scss, B.scss, ...
7. Дописывает js, и тоже часто разбивает: A.js, B.js, C.js
8. Какой-то бэкенд собирает из кусков шаблонов страницу, и часто создает css, js только из нужных кусков

А дальше: Пришел новый макет. И что делать?

И БЭМ в данном случае решает проблему, поскольку у него есть стек технологий, позволяющий верстальщику работать сразу с шаблонами и разобранными js/css(less/sass/stylus) файлами.

На практике получается так:
0. Макет.
1. Верстальщик смотрит на макет, и разбивает его на куски (компоненты) сразу;
2. Пишет bemjson (или jsx) вместо html;
3. Создает шаблоны, стили и js для каждого из блоков;
4. Передает это все бэкенд программисту (обычно через гит, потому что так удобнее);
5. Бэкендер без изменений использует эти файлы для генерации страницы, и просто генерирует описанный верстальщиком bemjson (или jsx).

И, О МАГИЯ, они могут работать над проектом параллельно, даже если придет новый макет.

C php действительно есть нюансы, которые сложно разглядеть, просто потому, что нет большого кол-ва пользователей и стек не устоялся.
Мы у себя используем велосипед, который собирает все сам, и почти готовы перейти на enb используя bh-php.
Большая проблема, как оказалось, использование декларативных шаблонизаторов — верстальщики не сразу въезжают что и как. Но когда въехали — я не знаю тех, кто возвращается на императивные (типа мусташей, джейдов, smarty, etc.).

Можно начать с https://github.com/bem/project-stub/tree/php-bem-bh и позадавать вопросы на форуме https://ru.bem.info/forum/ — люди поделятся своими историями.

Да, вполне рабочий вариант.

Нет ;-)

col-md-6 new-left — лучше унести в модификаторы b-layout

informers — это разметка? лучше как элемент разметки тогда.

b-inline — тоже скорее к разметке относится, лучше в элементом в b-layout или в специальный блок для разметки

auth-line — явно элемент auth-form, я бы сделал .form.form_auth или form_type_auth, а этот элемент — form__field.

ну и дальше в том же духе.

Один из простых способов:
1. Генерируем из исходного json по каким-то правилам bemjson c описанием структуры формы и блоков с элементами;
2. Используем https://github.com/bem/bem-forms как базу (или пишем аналог) для создания базовой библиотеки с шаблонами и базовыми типами полей и контролов;
3. На уровне проекта расширяем своими контролами (шаблонами, стилями, и т.д.);
4. Собираем чем-то стандартным, типа enb.

MVC для фронтенда не есть удачное решение, это становится очевидно, когда кол-во успешных MVC фреймворков для JS фактически равно нулю. MV* парадигма вполне работает, но без контроллеров.

С шаблонами мусташ ситуация следующая — либо не будет возможно доопределять трансформации, описанные шаблонами: т.е. придется копировать из исходной библиотеки шаблон и изменять его, в итоге проблемы при обновлениях; либо не использовать библиотечный подход для шаблонов вообще. Почему так: потому что mustache интерполируемый и императивный шаблонизатор, его технически нельзя научить доопределению. Если все же нужен именно mustache — достаточно будет написать технологию для enb, в гитхабе точно есть примеры для jade, и, кажется, некоторых других. По сути, пара несложных функций, где пишется: возьми этот файл как шаблон для шаблонизатора такого-то и создай из него функцию для отрисовки данных.

Если думаете про i-bem.js, то jquery у вас так и так будет (потому что i-bem использует jquery), с require.js — возможно, будет проще использовать ymodules: не сильно отличается от require.js, на нем уже основаны bem-core/bem-components и, соотв., bem-forms тоже, и взяв стандартный набор джентельмена от яндекса ничего не надо будет менять с этой точки зрения — все уже настроено.

Применять БЭМ-подход, не используя БЭМ-стек технологий, обычно больно, и так или иначе начинает писать свой БЭМ-стек технологий. Многие это проходили (если не все) и большинство перестали так делать.

А вообще, есть форум, где на такие вопросы отвечают намного быстрее и с примерами ;-)

Самый простой способ — это склонировать https://github.com/bem/project-stub через git, удалить папку .git, установить node, зависимости (npm install), и начать работать над проектом.

Чуть сложнее в настройке, но тоже простой — использовать yo и bem-stub, для этого нужно установить ноду, эти два пакета: npm -g install yo generator-bem-stub; и далее в новой папке можно будет запустить yo bem-stub, поотвечать на вопросы, и проект сгенерируется.

Важно понимать, что bem server скоро начнет внутри использовать enb, так что можно уже сейчас на него переходить и использовать enb server.

А вообще, на такие вопросы очень быстро можно получить ответ на bem.info и форуме. ;-)

Если проблема с bem-core, bem-components (в данном случае — первое) — забыли bower install, который должен устанавливаться при npm install. Еще bem server немножко устарел и лучше использовать enb server.

А вообще, на такие вопросы гораздо быстрее найти ответ на бем.инфо и форуме.

Инлайн стили это одно, а скрипты это другое, бэм собирает все вместе, и еще и html туда же при помощи i-bem.js

Примеры — многие проекты яндекса, часть мейл.ру, ну megafon.ru респонсив часть ;-) А вообще уже достаточно много сайтов на бем переходят.