Хочу в этой теме обсудить структуру проекта по бэму для верстальщика. Верстальщиком называю человека, который превращает PSD в html/css и немного js. Фронтендеры пишут жирный JS и БЭМ :)

Начну из далека. У обычных верстальщиков структура примерно такая (взято из TARS):

static/                                     #  Folder for static-files. You can choose the name for that folder in tars-config.js
    └── fonts/                              # Fonts (can contain subdirectories)
    └── img/                                # Images. You can choose the name for that folder in tars-config.js
        └── content/                        # Images for content (can contain subdirectories)
        └── plugins/                        # Images for plugins (can contain subdirectories)
        └── general/                        # General images for project (can contain subdirectories)
        └── sprite/                         # Raster images, which is included in png-sprite.
            └── 96dpi/                      # Images for displays with dpi 96
            ...
            └── 384dpi/                     # Images for displays with dpi 384 (more info in images-processing)
        └── svg/                            # SVG-images
    └── js/                                 # js
        └── framework/                      # js-frameworks (backbone, for example)
        └── libraries/                      # js-libraries (jquery, for-example)
        └── plugins/                        # js-plugins
        └── separate-js/                    # js-files, which must not be included in ready bundle
    └── misc/                               # General files, which will be moved to root directory of ready project — favicons, robots.txt and so on  (can contain subdirectories)
    └── scss  
        ├── entry/                          # Styles for entry points for css in case of manual css-processing More info [here](css-manual-processing.md).                
        └── etc/                            # Styles, which will be included in the end of ready css-file (can contain subdirectories)
        └── libraries/                      # Styles for libraries (can contain subdirectories)
        └── plugins/                        # Styles for plugins (can contain subdirectories)
        └── sprite-generator-templates/     # Templates for sprite generating
        └── sprites-scss/                   # Mixins for sprites
        ├── separate-css/                   # Css-files, which must not be included in ready bundle
        ├── common.scss                     # General styles
        ├── fonts.scss                      # Styles for fonts
        ├── GUI.scss                        # Styles for GUI elements (inputs, buttons and so on)
        ├── mixins.scss                     # Project's mixins
        ├── normalize.scss                  # Styles reset
        ├── vars.scss                       # Variables

Всё разделено по реализациям и технологиям, и всё инклюдится :)

В бэме эту структуру перевернули с ног на голову и засунули всё в блок.

button
  button.css
  button.js

Допустим у нас одностраничный сайт, и все блоки лежат плоской структурой. Уровней переопределения нет.

project
  index.html
  static
    header
    footer
    button
      button.css
      button.js

Если у нас несколько страниц сайта, то появляется необходимость выделить блоки страниц на отдельный уровень переопределения. К тому же, в этом проекте воспользовались несколькими сторонними библиотеками блоков, которые тоже следует выделить на отдельный уровень переопределения. Уже на этом этапе встает вопрос о том, как удобней и универсальней это сделать.

Первый вариант я подсмотрел в исходниках сайта bem.info.

project
  about.html
  index.html
  static
    blocks
      about               # 3 level
        button
      common              # 2 level
        button
      index               # 3 level
        button
    libs                  # 1 level
      foo-components
        button

Для меня основное неудобство этого варианта в том, что общие блоки common визуально смешиваются и теряются в дереве каталогов страниц.

Второй вариант - это явно указать где что лежит.

project
  about.html
  index.html
  static
    common                # 2 level
      button
    libs                  # 1 level
      foo-components
        button
    pages                 # 3 level
      about
        button
      index
        button

Остановимся на втором варианте. Теперь нам нужно сделать мобильную версию сайта. У нас уровни переопределения будут разветвляться на платформы desktop и mobile. При этом блоки common из общих для всех страниц, превращаются в общие для платформ.

Вариант "в лоб".

project
  about.html
  index.html
  static
    common                # 2 level
      button
    libs                  # 1 level
      foo-components
        button
    desktop
      common              # 3a level
        button
      pages               # 4a level
        about
          button
    mobile
      common              # 3b level
        button
      pages               # 4b level
        about
          button

Я считаю, что такой вариант имеет место быть, если вы не боитесь большой вложенности. Даже можно выделить в плюсы тот факт, что для реализации платформы mobile достаточно всего лишь дублировать папку desktop, переименовать и начать переписывать блоки.

Можно эту структуру представить в плоском виде. При этом в названиях папок через точку определять ее "тип". В этом месте мы подбираемся к "бэму головного мозга". Добавим к этому, что источников библиотек у нас стало несколько (допустим, они не пересекаются в плане используемых блоков).

project
  about.html
  index.html
  static
    bower.libs
      foo-components
        button
    common.blocks
      button
    desktop.blocks
      button
    desktop.pages
      about
        button
    mobile.blocks
      button
    mobile.pages
      about
        button
    npm.libs
      bar-components
        input

Схлопнутый вариант:

bower.libs
common.blocks
desktop.blocks
desktop.pages
mobile.blocks
mobile.pages
npm.libs

Если для генерации html использовать шаблонизаторы, то их можно хранить внутри блоков, либо как технология проекта *.templates.

Резюмируя, у меня получается такая структура проекта. Для собранной верстки с последующей отдачей бэкендерам, можно предусмотреть папки в технологии *.dist.

bower.libs
common.blocks
common.templates
desktop.blocks
desktop.dist
desktop.pages
desktop.templates
mobile.blocks
mobile.dist
mobile.pages
mobile.templates
npm.libs

Хочется определиться со структурой и придерживаться ее во всех проектах любой сложности. Надеюсь на вашу помощь в плане того, правильно ли я понял и применяю идею технологий реализации проекта как блока. Также очень интересно узнать как бы вы по бэму положили в проект шрифты, спрайты, переменные и миксины (SCSS, LESS).