Struggling to keep up with team changes across repositories? I built a local-first impact graph

Maintaining changes across multiple code repositories can be a complex task. Small modifications to one part of a multi-repository system can have far-reaching effects, impacting various components such as front-end wrappers, backend handlers, internal services, database calls, documentation, and tests. To address this issue, I developed Where am I, an MIT-licensed, local-first tool that generates a visual representation of the impact resulting from Git changes and static code evidence.

Where am I is currently an early version, and its output serves as supportive evidence for review purposes, rather than serving as a substitute for rigorous testing, security checks, or engineering judgment. When faced with a change, the question often arises: How does this modification propagate throughout the entire system? The answer may span multiple boundaries, including the front-end, API wrapper, backend route, handler or service, database or external API, OpenAPI documentation, and tests.

Traditional dependency graphs do not suffice in this scenario. While they illustrate relationships between components, they do not provide context on why those connections exist, which line of code created the relationship, and whether the node belongs to your current work or an incoming team change. To tackle these challenges, I established four design goals: local-first configuration, evidence over mystery, change-awareness, and bounded work.

The scanner, written in Node.js, gathers various perspectives of change for each configured repository. This includes working-tree and staged changes, commits on the current branch compared to its base reference, and changes available from the selected remote/base reference. The collected data is then combined with priority files and API catalog files, enabling the tool to establish connections between the changed implementation and related contracts, wrappers, documentation, and tests.

The extraction process relies on patterns such as functions and call relationships, API paths, frontend wrappers and backend handlers, database access, external HTTP requests, OpenAPI documents, documentation, tests, and application error codes. For instance, a test fixture includes a frontend fetch request, a Go route, a database call, an external training request, and a Python error code.

The generated graph incorporates nodes representing the handler, database, external call, error, and their respective relationships, along with evidence lines linking them back to the original source code.

The tool's configuration is explicit, with a minimal example allowing the discovery of repositories under a workspace directory. Repositories can also be listed individually, and scan limits can be adjusted according to the project's specific needs. The interface, built with React and XYFlow, presents separate views for current work, team changes, API contracts, and the analysis engine.

Users can search and filter the graph to focus on changed impact or items requiring review. Selecting a node or edge displays supporting details such as source evidence, representative diffs, relationship rules, change briefings, and suggested next checks.

While the tool aims to simplify the review process, it is not intended to generate the largest possible graph. Instead, it seeks to make the next review question easier to answer. It is important to note that local-first does not imply risk-free usage. The scanner reads source code from the configured repositories, potentially including absolute paths, repository names, branches, commit messages, pull request titles, function names, API paths, and evidence lines.

Therefore, it is recommended to review screenshots and exported output before sharing them, as local analysis may reveal information that was not intended to be public.

Current limitations include the pragmatic static extraction, which may miss dynamic calls, reflection, generated code, or complex metaprogramming. Coverage varies depending on the language and framework, and connections in the graph represent evidence worth inspecting, not definitive proof of all runtime dependencies. Future improvements will focus on developing language- and framework-specific extractors, providing confidence and explanation for inferred edges, enhancing graph behavior for large systems, and improving pull-request and branch comparison briefings.

To try Where am I locally, you will need Node.js 22.13 or newer and at least one local Git repository. Clone the repository, install dependencies, create a configuration file, and start the development server. The README provides PowerShell equivalents and details the full configuration options. Your feedback is particularly sought after concerning the most valuable language or framework extractor for your codebase.