When you open an unfamiliar repository, the folder structure rarely tells the whole story. Vibgrate Graph derives areas — natural communities of nodes that interact closely — directly from how your code actually connects. This article shows you how to discover them with vg areas and how to use them.
Overview
An area is a cluster of code nodes that depend on one another more than on the rest of the system. These communities are computed from the call and import graph, so they reflect real behavior rather than directory layout. Areas tell you where the genuine module boundaries are — which is often different from where the folders suggest they are.
Prerequisites
Make sure a code map exists and is current:
vg build
vg status
List your areas
vg areas
Each area is a group of related nodes. Skim the list to build a mental model: these are the functional neighborhoods of your codebase. A clean codebase tends to show areas that line up with features or layers; a tangled one shows areas that sprawl across unrelated folders.
What areas tell you
- Real boundaries. Areas reveal the modules that exist in practice, which informs how you split packages or services.
- Refactoring units. An area is a sensible unit to extract, test, or assign ownership to.
- Drift between intent and reality. If an area spans folders you expected to be separate, your structure has drifted from your intent.
Combining with other insights
Areas are the backdrop for the other map-level commands. Connections that cross between areas in surprising ways are exposed by vg oddities, and the nodes everything depends on are ranked by vg hubs. For a single overview that ties it together, use vg map.
To drill into any node within an area:
vg show
Related
- Detect architectural smells with
vg oddities. - Find hubs with
vg hubs. - Map the codebase with
vg map.
Like all Vibgrate Graph analysis, areas are computed locally and remain on your machine.