Graph reverted resolver

[qfox]

Need to grab this code bem-sdk-archive/bem-graph@79980d9 and make it up: wrote some tests, etc.

[veged]

Анализ архивного коммита и состояния 1.0.0

Архивный коммит — это bem-sdk-archive/bem-graph@79980d9 с сообщением «feat: experimental reversed flag» (важно: не "reverted resolver", а «reversed»). Это обратный обход графа — поиск множества вершин, которые зависят от данной (impact set / dependants).

Что делает архивный коммит (~26 LOC)

lib/mixed-graph.js: параллельно с _orderedGraphMap и _unorderedGraphMap заводится _reverseGraphMap. На каждое addEdge(from, to, { tech }) дополнительно пишется обратное ребро в reverse-карту. _getGraphMap начинает разрешать data.reversed → _reverseGraphMap.

lib/mixed-graph-resolve.js: resolve(..., reverse) — если reverse=true, полностью игнорирует ordered-обход (orderedDirectSuccessors = []), а неупорядоченные direct-successors берёт из reverse-карты.

lib/bem-graph.js: публичный API — dependenciesOf(entities, tech, reversed) + сахар reverseDependenciesOf(entities, tech).

Состояние @bem/sdk.graph@1.0.0

• В MixedGraph (src/mixed-graph.ts) только _orderedGraphMap и _unorderedGraphMap. Reverse-индекса нет.
• MixedGraph.directSuccessors не принимает reversed.
• resolve() (src/mixed-graph-resolve.ts) не имеет параметра reverse.
• BemGraph (src/bem-graph.ts) не имеет reverseDependenciesOf/directPredecessors/dependentsOf.

То есть функциональности «кто зависит от X» нет совсем — ни как публичного метода, ни как внутреннего обхода.

Применимость

Архитектурно совместимо. Структура MixedGraph (tech-bucketed map of DirectedGraph) идентична архивной, resolve использует те же directSuccessors. Портирование тривиально по форме.

Но слепое копирование не идеально:

1. Архивный код помечен experimental и жёстко зануляет ordered-обход в reverse-режиме. Это упрощение: в обратном направлении ordered-рёбра тоже несут смысл (предки в порядке зависимостей). Я бы предложил оба режима покрыть осознанно, а не зануляя.
2. Текущий directSuccessors в MixedGraph склеивает no-tech (null) и tech-specific подграфы. Reverse-индекс должен соблюдать ту же логику симметрично.
3. Удвоение памяти. Для большого графа лучше строить reverse-индекс лениво при первом запросе, а не на каждом addEdge.

Предложение по портированию (если делать)

Файлы:

• src/mixed-graph.ts — добавить reverse-карты (или ленивую стройку), параметр reversed?: boolean в EdgeData, ветку в _getGraphMap.
• src/mixed-graph-resolve.ts — параметр reversed?: boolean в resolve(), пробросить в directSuccessors. Сохранить поведение для ordered-рёбер (не зануляя, в отличие от архивного).
• src/bem-graph.ts — публичный reverseDependenciesOf(entities, tech) (или более внятное dependentsOf(...) / impactOf(...) — выбор имени стоит уточнить).

Тест-кейсы (новые файлы в src/__tests__/):

• reverse-deps-direct.test.ts — A→B→C, reverseDependenciesOf(C) = [B, A].
• reverse-deps-tech.test.ts — фильтр по tech.
• reverse-deps-multiple-roots.test.ts — несколько корней, дедупликация и порядок.
• reverse-deps-loops.test.ts — циклы: CircularDependencyError или безопасный обход.
• reverse-deps-no-tech-vs-tech.test.ts — склеивание null-tech и tech-specific.
• reverse-deps-ordered-vs-unordered.test.ts — поведение ordered-рёбер в reverse-режиме (зафиксировать выбор).

Риски

• Архивный коммит — экспериментальный; до релизного API он не дошёл. Возможно, авторы отказались по причинам, которых не видно в diff'е (память, семантика ordered). Перед портированием стоит просмотреть bem-sdk-archive/bem-graph issues/PR на ту же тему — нет ли follow-up'ов.
• Имя reverseDependenciesOf спорно. dependentsOf(x) («что зависит от x») или impactOf(x) («кого затронет изменение x») точнее по семантике.
• Связано с Возвращать массив BemCell из dependenciesOf #303: если решим менять dependenciesOf на BemCell[] — стоит сделать оба изменения сразу (один breaking).

Вердикт

Портировать стоит, но как 2.0-фичу (вместе с #303 и любым другим накопленным breaking-change'ем) и не копировать слепо — переписать с учётом замечаний выше. Объём: ~100-200 LOC + 6-8 тестов.

Если хочется в 1.x — можно добавить только новый метод (dependentsOf / reverseDependenciesOf) без трогания существующего dependenciesOf. Тогда это minor bump без breaking.

Жду решения по: (1) делать сейчас или ждать 2.0, (2) имя публичного метода.