// именованные типы бандлов (хз для чего)
describe('page', 'pages/*', function (node) {
  addTech('blabla', {yolo swag params}); // как обычно
  addTargets(['html', 'css', '?.min.css']);
  // если ? не указан и нет точки — достраиваем до "?.css"

  afterTargetReady('?.min.css', function (target) {
    cp(target.path, releasePath + '/' + target.relativePath);
  });
  afterEach(function () {
    // запускаем после завершения обработки всех таргетов
    sed(node.targets['css'], 's/script/script yolo="swag"/g', '-i'); // условно
  });
});
after(function () {
  // finalizing build
  // cd release; cap deploy?
});

Или даже так:

describe('page', {
  path: 'pages/*',
  yoloswag: 'yes'
}, function (node) {
  // ...
});

При этом технологии можно отдавать списом сервисов по тиму architect (в package.json, например, или отдельном файле), в запускалке можно сделать так, чтобы она смотрела все bem-* пакеты, установленные в node_modules, и собирала сама оттуда технологии. Если какой-то пакет будет предоставлять расширения — он их может просто проксировать через себя.

При этом можно таким же параметром передать describe('all-bundles', { include: '*.bundles/*, exclude: '*.bundles/merged', к вопросу о merged бандле, и после этого в merged бандле указать, что он {include: '*.bundles/merged', dependsOn: 'all-bundles'}. Кажется, что и просто, и понятно. При этом в технологии эта информация о бандле (и его "конфигах") тоже попадет.

/cc @blond @tadatuta @vithar @veged

Привет. Написал утилитку, которая умеет создавать и переименовывать бем структуру. Вот, решил попиарить, надеюсь кому-то еще будет полезна. http://habrahabr.ru/post/255195/

Всем привет!

Как настроить IDE для корректной работы с форматом *.bemhtml, как например в этом видео?

Устанавливал плагин BEM Support, но он не работает. Видимо потому, что поддерживает старый синтаксис.

Здравствуйте. Очень нравится оптимизированные файлы после cборки в bem-tools. Сейчас хочу переверстать сайт, построенный на фреймворке Yii при помощи БЭМ. Но появляется вопрос, как использовать склеенную borschik'ом разметку (c трудом читаемую на глаз) в разных layout-ах и элементах view. Думаю это актуально при любом паттерне mvc и разных фреймворках. Дайте пожалуйста рекомендации, как лучше и правильней. Может есть специальные ключи для разбивки исходного файла при сборке.

Кажется, что нужен новый формат deps.js :) Для сборки любым сборщиком было бы удобно получить массив из сущностей с указанием уровня и технологии. Данный массив должен быть таким, чтобы его можно было передать с фильтром (технология, [уровни]) на вход в метод concat. Вероятно там же необходимо указывать путь до файла с реализацией в технологии, если таковой имеется.

Может сделаем уже? @andrewblond можешь рассказать в каком состоянии модульная сборка? Кажется, что собранные депсы в один файл гарантируют возможность сборки с помощью любого сборщика любой технологии. Если продолжать писать руками депсы, то все будет хорошо) Возможно надо будет доработать депсы, чтобы было указание уровня для каждого блока. У кого какие мысли?;)

Вижу на странице:

TypeError: Cannot read property '0' of undefined
    at __$b29.iterateItems__$69 (.../users-list.bemhtml.js:501:46)
    at __$b29.iterateItems__$69 (.../users-list.bemhtml.js:509:21)
    at __$b29 (.../users-list.bemhtml.js:513:9)
    at __$g2 (.../users-list.bemhtml.js:1028:24)
    at applyc (.../users-list.bemhtml.js:33:20)
    at __$b75 (.../users-list.bemhtml.js:809:5)
    at applyc (.../users-list.bemhtml.js:105:20)
    at __$lb__$160 (.../users-list.bemhtml.js:784:22)
    at __$b74 (.../users-list.bemhtml.js:787:7)
    at applyc (.../users-list.bemhtml.js:102:24)

Реально ли собирать sourcemaps и при таких выбросах резолвить файлы/строки вменяемо?

Добрый вечер. Хочу попробовать внедрение методологии БЭМ в документировании принципов сборки приложения на основе общих высокоуровневых блоков (заголовок приложения, навигация, система уведомлений, справочники, компоненты и т.д.).

Что ожидаю получить:

• актуальная документация которую легко поддерживать
• общая терминология для всех участников процесса создания продуктов
• UX-проектировщик упорядочивает свои решения и формирует библиотеку общих решений
• UX-проектировщик занят актуальными проблемами вместо перерисовки устаревающих макетов
• менеджеры проектов пользуются документацией и применяют описанные решения
• менеджеры проектов дают обратную связь и участвуют в развитии общей документации
• менеджеры проектов совместно с UX-проектировщиком доопределяют документацию согласно требованиям своего проекта
• программисты пользуются документацией
• программисты понимают где собрана вся документация по определённому блоку
• программисты понимают, что пытался донести UX-проектировщик
• менеджеры проектов и программисты имеют доступ к примерам как стоит и не стоит использовать блоки
• продукты компании выполнены в общем стиле и с единым подходом к навигации, структуре контента и т.д.

Что потребуется:

• Терминология, принципы именования и размещения на файловой системе - заимствуются у БЭМ
• Выбор технологий для описаний, макетов, примеров
• Инструменты и технологии сборки
• Технология публикации артефактов и документации (сайт)
• Упоротость и удача
• Преодоление множества "подводных граблей" на пути к мечте

Данный пост можно рассматривать:

• попытку определить и упорядочить цели и задачи
• сбособ получить критику, замечания и напутствия от сообщества

Часто структура проекта на bem выглядит как-то так:

desktop.bundles
  |--somebundle
       |--blocks
       |--somebundle.bemdecl.js

После сборки enb складывает всё что он насобирал в somebundle. Проблема в том, что в WebStorm нельзя исключить из проекта только часть директории. Кто как решает эту проблему?

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

https://github.com/zxqfox/express-bem

И 3 плагина — .bemhtml.js, .bemtree.js, и собственно make через bem-tools.

Технически, наверное, .bemhtml.js может подключать и .bh.js, для этого нужно только подменить расширение, но протестировать не на чем.

Проект сыроват, хочется критики и идей. Если найдутся смельчаки и протестируют проект на enb — будет здорово. А если еще и соберут мидлварь для него — вообще замечательно.

Спасибо за внимание ;-)

Analyze — пакет, который строит объектную структуру проекта. Первая цель — генерация UML-диаграмма классов и взаимодействий, которая бы не протухала.

Анализ структуры проекта и связей между ними.

Работает на провайдерах.

Подходит для BEViS-проектов, но сама структура не слишком завязана на BEViS, т.к. используются достаточно абстрактные сущности.

Но провайдер jsdoc работает на BT-шаблонах.

Есть провайдер для модульной системы, написанной dfilatov.

Есть дополнения.

CLI Единственная команда report — загружает конфиг .analyze.js (если есть), вынимает оттуда директории проекта, анализиует проект (все файлы с расширением js, но не test.js). Каждый файл обрабатывается отдельно.

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

Пост-обработка — построение зависимостей (между классами).

Набор зависимостей — это отдельная сущность.

Обработка:

1. Фильтры (из общей структуры остается какой-то необходимый сабсет) source target show — общая картина, все связи (source + target)
2. Валидация (не связан со структурой, указывает на какие-то несоответствия, например, обязательное наличие return type) ErrorLog — в него пишут провайдеры и валидаторы Валидаторы имеют настройки в CLI.

На данном эта получаем Объектная модель (инстанс Project) и инстанс ErrorLog (включает указание на строку с ошибкой)

1. Репортер

Настройка node.js-модуль экспортирует функцию, которая настраивается конфигуратором.

Планы на будущее Команда репорт не будет иметь предустановленных стратегий анализа (стратегии будут описываться отдельно). Будет возможность в js-файле описывать стратегии.

Хочется: builder (сделать настраиваемый, который бы можно было переопределять) стратегии (какой проект) вызывает процессоры про каждую сущность

file-analyzer -> js-file-analyzer

История разработки

BT-json -> MD + вставки ```BT-json, примеры и документация по js из jsdoc.

BEViS-doc-builder включает две технологии для генерации одно- и многостраничной (для Dash) документации.

---

Есть предложение, что нужно делать tool-chain из модулей с API, решающих конкретные задачи. И в этом контексте есть идея, что можно вынести из ENB ядро (task + node + target), для решения задачи сборки без привязки к предметной области.

У Марата нет уверенности, что устройство на node&target — это хорошо, т.к. понятие ноды излишне конкретное. Для сборщика общего назначения есть смысл оставить только target-ы (таски).

---

node - это папка (частный случай task) target - файлы либо папки, которые лежат в node task - как в Гранте, но без параметров (именованная задача, которая может использовать другие task).

Здесь собираем варианты API TechBuilder, выбираем наиболее подходящий.

https://github.com/bem/bem-tools/pull/502

// cc @zxqfox