graphlens: превращаем репозиторий в типизированный граф — Python, TypeScript, Go и Rust в одной модели

[crazyrock]

Существует альтернатива - graphify, и там звёзд побольше будет. На первый взгляд эти инструменты решают одну и ту же задачу. Есть ли какие-либо преимущества перед конкурентом?

[Neko1313]

Graphify — это Claude Code skill для конечного пользователя, graphlens — движок. По резолвингу: graphify делает name-based matching через AST + LLM-угадывание, сами помечают это как INFERRED. graphlens гоняет реальные тайп-чекеры (ty/gopls/rust-analyzer/tsc) — ребро CALLS указывает на конкретный объявленный узел, не на строку с именем. Это разные инструменты для разных задач, сравнение по звёздам бессмысленно.

[crazyrock]

Благодарю. Жаль, что Ваш продукт так ограничен в выборе языка

[Neko1313]

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

[Tim02]

Хотелось бы в php попробовать

[Genius_Russian_Coders]

Adapter → IR → backend — грамотно. А как с динамическими вызовами в Python (getattr, importlib)? Tree-sitter их не ловит, и граф вызовов будет неполным для реальных проектов.

[Neko1313]

Справедливое замечание. getattr/importlib — это known limitation любого статического call graph: без runtime информации такие вызовы в принципе не разрешимы полностью. В текущей реализации они либо не формируют CALLS-рёбра вообще, либо резолвятся в EXTERNAL_SYMBOL(unknown) — граф деградирует в этих местах, но не ломается (resolver_status всё равно будет ok, что технически не совсем честно для таких паттернов).

На ty-стороне пока не исследовал, насколько он это покрывает — он pre-1.0 и поведение нестабильно. Pyright теоретически чуть лучше с getattr(obj, name) где тип obj известен, но это: а) не универсально, б) существенно медленнее индексация. Скорее всего трекну это как известное ограничение и буду ждать ty 1.0, где type inference должен быть значительно зрелее.