Не вешай нос, уже есть начало bem-tools 2.0, и точно будут адаптеры для enb технологий — это сделать просто и это сделать нужно.

Базовые модули:

• bem-naming
• bem-object
• bem-walk
• bem-decl
• возможно другие.

Кроме того, многое из того, что есть уже сделано хорошо и это можно будет использовать практически as is либо с небольшими фиксами.

@andrewblond имеет глубокое понимание проблемы и занимается этим по мере наличия сил, я надеюсь ;-)

Да я видел обсуждения по bem-tools 2.0, и до какого момента понимал куда все движется, но после некоторых событий понимание стало другим, а теперь совсем запутался.

Я уверен что bem-tools заморожен 2.0 не светит, есть апстрим выделять все в атомарные модули, как можно видеть, твердая почва для рядового кодера может появится только тогда когда он дорастет до билдер-мейкера.

Если говорить конкретнее о bem-tools 2.0 — там должен быть сборщик, по гибкости совпадающий с enb (типа гульпа/броколей), но и система плагинизации, схожая с bem-tools 0.x, но более свободная — выдающая наружу некое ядро, которое можно будет расширять как руками, так и готовыми плагинами.

Как вариант — ym, используемый под nodejs. Если такой способ всем нравится, то есть еще два варианта готовых модулей — pym, пакеты на базе ym, и architect со своим апи, тоже с асинхронным provide, но более строгий и без доопределения (если не вру). На базе чего-то такого и coa можно легко вклиниваться в ядро, предоставлять какие-то сервисы, используя уже имеющиеся куски ядра и подключенных модулей, доопределять уже имеющиеся, в новых сторонних модулях и тулзах, типа bem create/build/cp/mv/etc.. Учитывая, что все знают modules, и написать что-то вроде modules.require(['bem-storage'], function (storage) { console.log(storage.getBlocksList()); }); доступно будет каждому, потому что все эти базовые модули можно будет отдельно пилить, писать на них тесты, заменять один другим, описывать их апи и зависимости, и жить счастливо ;-)

upd: Более того, если мы вменяемо научимся абстрагироваться от файловой системы и работать с именованными потоками и запускать сборку при чтении из этих потоков, а это, на мой взгляд, не рокет сайнс, когда есть gulp и желающие это делать (привет @floatdrop), то все станет еще проще, поскольку можно будет как пользоваться bem-tools 2.0, так и писать конфиги прямо в гульп и рулить все самим. Это позволит технологиям развиваться отдельно от ядра, и не надо будет ванговать разработчикам самого ядра. Может, конечно, это слишком революционный путь и разрабы ядра бт2.0 просто захлебнутся, но если ядро будет тупо связующим звеном, а задачи будут ясными-понятными (а в этом случае они будут по требованию с конкретными хотелками) — подтянется сообщество 100%. Т.е. на мой взгляд это наоборот вполне логичный путь, но хоть он и императивный — у нас есть тонны опыта, чтобы двигаться еще дальше и развиваться еще и в ширь.

Все так. На сегодняшний день любой проект на полном БЭМ-стеке можно собирать как с помощью bem-tools, так и на ENB, так что появился выбор.

Но действительно bem-tools в текущем виде прямо сейчас активно никто не развивает (хотя мы в ближайшее время выпустим фикс под Windows и, заодно, появится поддержка require).

А ENB действительно не лишен недостатков, о которых говорит @zxqfox. Другое дело, что у части из них есть понятные решения. Например, вот так выглядит конфиг для сборки внутренней библиотеки, поддерживающий полностью все те же задачи, которые есть в bem-components:

var LIBRARIES = [
        'libs/islands-romochka',
        'libs/islands-icons'
    ];

module.exports = function(config) {

    config
        .includeConfig('enb-islands-tools')
        .module('enb-islands-tools')
        .configureProject({
            libraries: LIBRARIES,
            examples: true,
            docs: true,
            tests: true,
            specs: true,
            tmplSpecs: true,
            tmplSpecsOptions: {
                bemhtml: true, //использовать bemhtml в тестах на шаблоны
                bh: true, //использовать bh
                useDataBemInBh: true //использовать data-bem аттрибут в bh
            }
        });

};

Т.е. когда понятно, какие кейсы реально используются, нет проблемы завернуть всю «какашку» в удобное API. Мы подобную обертку выложим и в open source, просто для внешних проектов не так просто учесть все варианты использования.

И да, мы с 2013 года обсуждаем возможность перейти на модульную сборку, которая бы позволила собирать БЭМ-проекты чем угодно. Шаги в этом направлении делаются, но пока, к сожалению, я не могу обещать каких-то конкретных сроков. Тем не менее, на уровне proof of concept она уже работает.

@tadatuta Да, я все время забываю про всякие хелперы в config. ;-( Простите уж.

@ilyar заморожена работа по bem-tools@v1, а то, что мы называем bem-tools 2.0 никак не связано с текущей кодовой базой bem-tools, это полностью новый подход и работа в этом направлении медленно, но движется.

@tadatuta полезная информация есть где то об этом подробнее?

@ilyar Ссылки, которые привел @zxqfox — это то, что уже сейчас есть по bem-tools 2.0. На хакатоне @andrewblond с @floatdrop смогли на основе этих модулей собрать тестовый проект на базе gulp, но до продакшен-решения там еще очень много работы.

В целом рекомендую фолловить @andrewblond — все, что он делает, делается изначально на github'е.

@tadatuta уверен что со мной согласятся многие, если писать о заморозке **bem-tools** это одно понимание, а если писать заморозке **bem-tools 1.0** и разработке **bem-tools 2.0** которое является не приоритетным и нет никаких сроков и поэтому сейчас ENB рулит это другое понимание.

Пожалуй, отвечу заранее на вопрос «Зачем нам под нодой асинхронный реквайр?»: Во-первых, если кол-во плагинов и модулей разрастется до 30-50, которые будут друг друга реквайрить внутри, то загрузить их достаточно быстро, но инициализировать будет долго. Например, чтение большого проекта будет подвисать, когда как для некоторых команд, типа создания блока, это будет лишним, поскольку достаточно будет только информации об уровнях и технологиях по умолчанию. Во-вторых, асинхронные реквайры позволят делать всякую магию с автодогрузкой модулей при необходимости и частичной сборкой. Если вы скажете, что это никому не нужно — то вы заранее отбираете у потенциальных пользователей эту возможность, что делает ядро сильно менее универсальным. Завернуть что-то единожды при разработке плагина, во что-то типа modules.define или прописать ему зависимости и реализации, не такая уж крупная потеря, но потерять возможность делать асинхронщину много хуже.

Хочется, конечно, послушать и ваши доводы по этому поводу.

За что отвечает пакет bem-walk?

@ilyar :+1: Но по факту в ближайшие 2-3-6 месяцев врядли будет что-то bem-tools2.0 продакшн риди.

@ilyar bem-walk это low-level интроспекция проекта.

Еще один кейс для асинхронщины — проверка обновлений в bg с выводом сразу, если возможно, либо со складыванием в кеш и последующим выводом.

bem-walk это low-lever интроспекция проекта звучит круто, раскрой немного, что бы было совсем всем понятно. Хочется верить что создаю полезные топики для всех, а не только для себя любимого.

@ilyar Фактически, это очень простой кирпичик, который ходит по уровням и собирает о них информацию, и возвращает пачку bem-object с данными о блоке.

@ilyar

если писать о заморозке bem-tools это одно понимание, а если писать заморозке bem-tools 1.0 и разработке bem-tools 2.0 которое является не приоритетным и нет никаких сроков и поэтому сейчас ENB рулит это другое понимание.

Мы примерно так и сказали в посте про заморозку:

И как мы неоднократно рассказывали на BEMup-ах, мы прекратили разработку bem-tools 1.0, но продолжаем мечтать о том, чтобы написать набор атомарных модулей, которые будут позволять собирать БЭМ-проекты с помощью grunt, gulp, broccoli, brunch и т.д.

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

@zxqfox предлагаю унести обсуждение про асинхронщину в отдельный топик и призвать к ответу @andrewblond, у меня пока определенного мнения нет.

@tadatuta Каюсь, создал: http://ru.bem.info/forum/issues/132/

Добавлю ко всему выше скзанному, что сейчас очень много проблем из за отсутствия спецификации на deps и сопутствующие части (да @tadatuta ?). Мы очень много времени на хакатоне потратили на изучение deps-resolver и зачем ему вообще decl (когда он отличается от deps только полем name - которое в другом block, но значение имеет принципиально то же).

@ilyar, @zxqfox, @tadatuta Предлагаю не использовать термин bem-tools 2.0, это всех путает. В последнее время у нас, вроде бы, устоялся другой термин — «Модульная сборка». Из него немного понятнее каких задач мы хотим решить на самом деле.

@floatdrop, очень сильно согласен =) Но decl с полем name и т.д. это просто реализация в ENB, и в спецификации об этом не будет ни слова.

Что касается ENB проблем, то их можно разделить на 2 части: проблемы архитектуры и проблемы конкретной реализации.

Конфиг в ENB декларативный, и поэтому он выглядит сложнее, чем любой императивный. При этом он удобнее в каком-то смысле, так как позволяет доопределять сборку нод. node/target-архитектура хорошо ложится на сборку бандлов, но и привносит много ограничений и сложностей.

На данный момент для всего многообразия задач при разработке библиотек блоков ENB, на мой взгляд, лучшее решение, поэтому мы сами им и пользуемся. Но если попробовать решить архитектурные проблемы в ENB, то придётся написать его с нуля, и это будет уже не ENB =)

Что касается проблем реализаций, то решать их можно, что мы и делаем. Например, в enb-bem-techs сильно улучшено API технологий.

@andrewblond ENB никто не хочет пириписывать, потому что в этом нет смысла. Но совместимость с технологиями enb поддержать смысл есть, и проблем с этим нет ;-)

За улучшения API отдельный респект ;-) Но имхо пора делать следующий шаг