Мы подумали, что в БЭМ терминах можно выразить весь проект целиком.

В этом случае корень проекта становится уровнем со своими правилами именования. Например, правила такие, что блоки лежат на этом уровне плоским списком.

.bem/

    level.js

/* файлы проекта */

Каждый уровень в корне проекта — уровни с блоками или бандлами (страницами) — это реализация соответствующего блока в технологиях blocks или bundles.

common.blocks/

    .bem/

        level.js

    /* блоки */

touch.blocks/

    .bem/

        level.js

    /* блоки */

touch.bundles/

    .bem/

        level.js

    /* бандлы */

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

bem-bl.lib/

    .bem/

        level.js

bemhtml.lib/

    .bem/

        level.js

Библиотека, в свою очередь, так же является уровнем-проектом. Получаем фрактальную вложенность.

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

common.blocks/
    .bem/
        level.js
    button/
        button.css
        button.bemhtml
        button.examples/
            01-basic/
                01-basic.bemjson.js

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

common.blocks/

    .bem/

        level.js

    button/

        button.css

        button.bemhtml

        button.examples/

            01-basic/

                01-basic.blocks/

                    .bem/

                        level.js

                01-basic.bemjson.js

При таком подходе к организации кода примеров мы можем создавать примеры не только для блоков, но и для любых других БЭМ сущностей — элементов, модификаторов и их значений. А при генерации страницы с документацией показывать эти примеры контекстно по месту, рядом с описанием конкретной БЭМ сущности.

То же самое с общей документацией проекта. Можно располагать её на отдельном уровне, каждый документ представлять в виде отдельного блока, а каждый раздел документа — в виде элемента.

docs/
    .bem/
        level.js
    tutorial/

        tutorial__intro.md

        tutorial__step1.md

        tutorial__step2.md

        tutorial__step3.md

Если звучит сложно, представьте, что уровни — это папки, а БЭМ-сущности, выраженные в технологиях — это имена файлов с расширениями. Технология — это расширение, а БЭМ-сущность — это сложносоставное имя файла.

Если вы думаете о том, что поддерживать такую структуру руками будет непросто — у нас есть инструмент bem create, который как раз призван эту задачу решать. Например, создать проект можно так:

bem create -T project -b my-new-project

Создать уровни блоков и бандлов в проекте так:

bem create -T blocks -b common -b desktop
bem create -T bundles -b desktop

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

Чтобы сократить эти команды, можно заводить алиасы в shell. Мы также думаем над тем, чтобы дать возможность заводить алиасы на уровне команды bem (как в git) как только для себя, так и для конкретного проекта или отдельного уровня.

Такой подход к описанию структуры всего проекта поможет нам упорядочить описание правил сборки для bem make / server, устранить некоторые несостыковки. Кроме этого, мы сможет автоматически делать интроспекцию всего проекта по файловой структуре, что поможет нам сделать такие инструменты, как bem ls, bem find и т.д.

А как вам такая структура?