Comments 7
Существует альтернатива - graphify, и там звёзд побольше будет. На первый взгляд эти инструменты решают одну и ту же задачу. Есть ли какие-либо преимущества перед конкурентом?
Graphify — это Claude Code skill для конечного пользователя, graphlens — движок. По резолвингу: graphify делает name-based matching через AST + LLM-угадывание, сами помечают это как INFERRED. graphlens гоняет реальные тайп-чекеры (ty/gopls/rust-analyzer/tsc) — ребро CALLS указывает на конкретный объявленный узел, не на строку с именем. Это разные инструменты для разных задач, сравнение по звёздам бессмысленно.
Adapter → IR → backend — грамотно. А как с динамическими вызовами в Python (getattr, importlib)? Tree-sitter их не ловит, и граф вызовов будет неполным для реальных проектов.
Справедливое замечание. 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 должен быть значительно зрелее.
graphlens: превращаем репозиторий в типизированный граф — Python, TypeScript, Go и Rust в одной модели