[Feature] Flutter and Dart support

[dacianf]

Problem

I saw your project and I would love to integrate it on a Flutter project.

Proposed Solution

I think it should to a parse of files + widget tree understanding and classes hierachy.

Alternatives Considered

I used grapify, but it only does a code file graph with no context of what's inside or how some relate.

Additional Context

Flutter whole UI structure is having a widget tree. For the AI to be able to easily reuse components and UI code it needs to understand the project widget tree, how the files relate what what's for us. Ideally a link maybe with the compiler sematics and analysis can work too. I'm not sure.

I'm open to fork and build a solution, and create a PR, but I need a bit more guidance to understand what's important and what's not from the LLM perspective

[RaghavChamadiya]

Hey @dacianf — thanks for the offer to contribute! Dart is on our roadmap (targeting "Good" tier, tree-sitter-dart is available), so a PR would be very welcome.

The full guide for adding a language lives in docs/LANGUAGE_SUPPORT.md. Quick orientation for Dart/Flutter specifically:

Phase 1 — Dart language support ("Good" tier). Follow steps 1–8 in the doc:

1. Add a LanguageSpec for Dart in packages/core/src/repowise/core/ingestion/languages/registry.py (.dart ext, entry points lib/main.dart / bin/main.dart, manifest pubspec.yaml).
2. Add "dart" to the LanguageTag literal in models.py.
3. Write queries/dart.scm — model it on typescript.scm (Dart has classes, mixins, extensions, named/factory constructors). Capture @symbol.def/name, @import.module, @call.target/receiver.
4. Add a LanguageConfig in parser.py.
5. Add tree-sitter-dart to pyproject.toml.
6. Bindings extractor in extractors/bindings/dart.py (handle import 'pkg.dart' as p show A hide B).
7. Heritage extractor in extractors/heritage/dart.py (extends, implements, with mixins, on clauses for extensions).
8. Import resolver in resolvers/dart.py — this is the trickiest piece. Dart has four import schemes:
   • package:foo/bar.dart → resolved via pubspec.yaml + .dart_tool/package_config.json
   • dart:async → external/SDK (skip resolution)
   • relative './util.dart'
   • part of / part directives — needs a small extra pass since parts share a library

What matters most from an LLM perspective (your question): for code-understanding, the highest-leverage signals are (a) the import graph, (b) class/mixin/extension heritage, and (c) call edges. Get those three right and you cover ~80% of the value. Fancy widget-tree understanding can come later.

Phase 2 — Flutter widget tree (separate PR). This belongs in framework_edges.py alongside Django/Spring/Rails. The win is recognizing build() methods returning widget trees and emitting parent→child edges between StatelessWidget/StatefulWidget subclasses. I'd suggest landing Phase 1 first, then iterating on framework edges with a real Flutter project as a fixture.

Drop a small Flutter sample under tests/fixtures/ and a unit test mirroring the existing Kotlin/Swift test layout. Happy to review a draft PR — feel free to open it early as a draft if you want feedback before the resolver work.