How it works

Weftmap does static analysis: it reads your code without running it and infers the relationships from the syntax tree.

The pipeline

• Parsing — each file is parsed with tree-sitter, producing a real syntax tree (not regex).
• Symbol table — the functions and classes defined in each file are collected.
• Imports— each import is resolved to its file, following the language's rules.
• Calls — each call is linked to its definition: local first, then an imported file, and if there is a single global candidate, that one.
• Classes & inheritance — methods are attributed to their class and extends relationships are traced.
• Layout — grouped into modules › classes › methods and positioned with a hierarchical layout.

Graph model

Three node types (module, function, class) and three edge types:

• calls — between functions/methods.
• imports — between modules.
• extends — between classes.

SQL: a different diagram type

SQL produces an entity-relationship diagram, not a call graph: tables are nodes (with columns and PK/FK keys) and foreign keys are referencesedges with cardinality. More in Reading the diagram.

Safety & performance

• Parsing each file is time-capped so a pathological input can't block the server.
• There are 2 MB and 400-file limits per analysis (see API reference).

Known limitations

Resolution is name-based, not type- or scope-aware. That means:

• Two functions (or methods of different classes) with the same name merge into one node.
• Dynamic dispatch, eval, reflection and indirectly-invoked callbacks are not followed.
• Calls to external libraries are skipped (only definitions in your code are linked).
• In Go, package-based imports are not mapped to files.
• For now you upload a folder (no .zip files yet).