Раз уж речь о депсах, я бы предложил разделить необходимость подключения зависимости и порядок включения. Как уже замечали, should, must и include: false - непонятная и нелогичная штука. Например:

{
    deps: [
        {block: 'a'},
        {block: 'b'}
    ],

    includeBefore: [
        {block: 'b'},
        {block: 'c'}
    ]
}

Вместо forEach, я бы предложил метод query с DSL для запросов:

deps.query({block: 'a'}) - получить все непосредственные зависимости блока a. deps.query({block: 'b', tech: 'js']}) - получить все непосредственные зависимости блока b для его технологии js. deps.query({block: 'с', tech: 'js', full: true}) - получить полный граф зависимостей для блока c (включая зависимости его зависимостей и т.д.). TODO: придумать лучшее название параметру full.

Можно посмотреть на TaffyDB, можно придумать более специфичную для нас структуру хранения данных.

@SevInf Про query() интересно, нужно больше подробностей и примеров использования.

Типовые задачи:

• получить список зависимостей для сборки js (или любой другой технологии)
• получить список bemhtml зависимостей для сборки js (собирать для клиента только нужные шаблоны)
• получить полный список зависимостей для сборки css (к обычным прямым зависимостям добавляются зависимости других технологий от css)

Был недавно ещё топик про то, что при сборке бандла css нужно собирать для всех блоков, а при сборке ie.css нужно некоторые зависимости отменять. Надо подумать, можно ли это выразить.

получить список зависимостей для сборки js (или любой другой технологии)

.query({tech: 'js'});

получить список bemhtml зависимостей для сборки js (собирать для клиента только нужные шаблоны)

.query({tech: {'js': 'bemhtml'}})

получить полный список зависимостей для сборки css (к обычным прямым зависимостям добавляются зависимости других технологий от css)

.query({tech: 'css', full: true}), если я правильно тебя понял.

Был недавно ещё топик про то, что при сборке бандла css нужно собирать для всех блоков, а при сборке ie.css нужно некоторые зависимости отменять. Надо подумать, можно ли это выразить.

Тут пока затрудняюсь хорошо ответить. Возможно, какой-то параметр вроде skip поможет:

.query({tech: 'ie.css', skip: {block: 'noie'}});

получить список bemhtml зависимостей для сборки js (собирать для клиента только нужные шаблоны) .query({tech: {'js': 'bemhtml'}})

Не смог осмыслить почему так.

Посмотрел на deps-resolver из enb. Тестов на него нет, jsdoc минимальный, и комментариев по коду нет совсем.

Понять, как оно используется можно из кода технологии deps.js.

Особенности реализации:

• захардкожено знание про BEViS (view, skin) вперемешку со знанием про БЭМ (block, elem, mods)
• конструктор на вход получает объект levels, в котором в особом формате содержится информация обо всех файлах на всех уровня переопределения, участвующих в сборке
• захаркожено знание про deps.js и deps.yaml файлы (if в коде в нескольких местах)
• отсутствует реализация зависимостей по технологиям (нашёл про tech ровно один if)
• файлы с зависимостями читаются во время добавления очередной декларации вызовом addDecl()

Есть ещё набор хелперов для работы с зависимостями в модуле lib/deps/deps.js.

Зависимости по технологиям реализованы в отдельной технологии bemdecl-from-deps-by-tech.

Идея там в том, что перебираются все файлы зависимостей из levels, и собираются все зависимости, где tech равна указанной в конфиге технологии sourceTech. Из этих собранных зависимостей собирается bemdecl.js файл, который потом используется в цепочке сборки bemdecl.js -> deps.js -> технология. Недостаток в том, что так не соберёшь все нужные css, например (как мы делали в bem-techs-core).

@SevInf

Раз уж речь о депсах, я бы предложил разделить необходимость подключения зависимости и порядок включения

includeBefore не очень понятно. Что именно должно быть before, то что в списке ниже или то, к чему описываются зависимости? При этом include намекает на необходимость включения.

Может, лучше deps и priority? deps определяет зависимость от, а priority определяет только приоритет включения.

Чтобы задать и зависимость, и приоритет, нужно будет определить сущность в двух списках. Может, стоит предусмотреть дополнительное поле priority в сущностях, которые указываются в deps? И, если зависимость нужна раньше описываемой сущности, выставляем флаг priority: true. Примерно так сделано в deps.yaml в enb. Но отдельный список будет по-прежнему нужен для описания приоритета без включения зависимости.

@SevInf Добавил входной формат в issue description. Норм?

priority мне тоже не очень нравится, особенно запись priority: true с толку сбивает. Может, лучше placeFirst? Неочевидности нет, ясно что то что в списке размещается сначала.

priority мне тоже не очень нравится, особенно запись priority: true с толку сбивает. Может, лучше placeFirst? Неочевидности нет, ясно что то что в списке размещается сначала.

high-priority, foremost, primary, essential, important?

@veged в старой переписке предлагал orderedDeps/unorderedDeps.

замечания к этому варианты возникли такие:

1. не очевидно, почему ordered — это про то, что будет подключено до.
2. слово deps очевидно из того, что мы пишем это в файле deps.js и его можно опустить.

Еще варианты из переписки: precedingDeps (preDesp) / depsBefore / beforeDeps / priorDeps / aheadDeps / depsAhead (и они же без Deps)

link + linkBefore

@scf2k

high-priority, foremost, primary, essential, important

preceding

Предложение priority должен иметь цифровое значение (0, 1, 2...10), если он не указан то вычисляется подобно тому как это сделано в xslt алгоритм вычисления задокументировать и при необходимости сделать возможным переопределять подобно тому как планируется сделать с правилом наименования.

@ilyar что будет означать, например, { priority: 4 }?

@ilyar priority в XSLT одна из самых сатанинских штук (сразу после "веса" матча) — добавляет слишком много не очевидного и очень багогенна

в { priority: 4 } не больше смысла чем в { priority: 'primary' }, общий принцип чем больше priority тем выше блок.

Вероятно, я не до конца понимаю какую задачу решает priority, можно несколько кейсов?

Возможно будет полезен наш опыт по приоритезации БЭМ-сущностей, для подключения зависимостей в правильном порядке.

Приоритеты БЭМ сущностей

Сразу прошу прощенья, если не в кассу :)

Мы обсуждали и пришли к тому, что mustDeps можно заменить на require, а shouldDeps на expect

@veged, по-моему, require и expect — звучат лучше всего предложенного. как смотришь на добавление таких алиасов?

ну если все считают, что это понятнее, чем must/should, то я не против ;-)