Skip to main content

Analysis Pipeline

DependencyAtlas uses a staged pipeline rather than a monolithic source scanner. The important boundary is that DepAtlasSource emits typed structure and call facts, and later phases operate on those typed records.

Pipeline At A Glance

01

Discover

Resolve project roots and collect Julia files plus source lines.

02

Scan

Extract raw JuliaSyntax facts from each file.

03

Lower

Turn syntax facts into ownership-aware structure and call facts.

04

Build

Apply typed structure and call facts to produce the canonical base graph.

05

Persist & Query

Persist the source-owned snapshot, then project, filter, and query it without rerunning analysis.

1. File Discovery​

The task runner resolves the project root, discovers Julia files, and records file contents in lines_by_rel_file for later semantic annotation.

2. Syntax Facts​

DepAtlasSource parses source files with JuliaSyntax and emits raw syntax facts such as:

  • modules
  • imports/usings
  • includes
  • method definitions
  • generic declarations
  • macro definitions
  • body call, binding, and return facts

At this stage the facts are still close to syntax and are not yet graph objects.

Keep this boundary in mind

If a future parser change should not ripple into the rest of the backend, the missing abstraction is almost always in lowering, not in the later graph builder.

3. Lowering and Ownership​

Lowering turns syntax facts into stable typed facts by rebuilding:

  • owner module
  • owner method
  • executable body ranges
  • local module-valued bindings

This is the stage that makes the later graph builder independent of the concrete parser while keeping the hot path strongly typed.

4. Canonical Graph Construction​

Typed structure facts are applied to build the base graph:

  • file nodes
  • module nodes
  • method nodes
  • include/import/define edges

Then define-time overload annotation rewrites Julia extension semantics into explicit metadata.

5. Call Resolution​

Typed call facts are applied after the base graph exists. This lets the resolver:

  • prefer internal targets when available
  • use lexical/module binding information
  • fall back to external method nodes when needed
  • annotate call evidence with overload and external-group semantics

6. On-Demand JET Views​

JET runs are separate from base graph construction:

  • on-demand JET views from selected method nodes

Each run creates or reuses a cached pure-JET graph view. It does not rewrite the main DepAtlasSource snapshot.

7. Snapshot and Query​

The final graph is stored as an immutable snapshot. Query-time logic then provides:

  • method/file/module projection
  • filtering and pagination
  • reachability traversal
  • query-context metadata such as node_appearance

Overload semantics and appearance semantics are therefore split between build time and query time by design.

Source Pipeline vs Query Runtime​

Keep two tracks separate:

  • JuliaSyntax mainline work
    • syntax facts
    • lowering and ownership
    • call extraction
  • query/runtime work
    • projection
    • pagination
    • reachability
    • node_appearance

Both affect the user-facing graph, but they solve different maintenance problems.