DEV Community: soil0119

Tracking code changes in plain folders with Where am I

soil0119 — Tue, 13 Oct 2026 06:40:18 +0000

A source folder can contain several services, API definitions, and tests before it has a useful Git history. I have added plain-folder tracking to Where am I, an MIT-licensed tool for inspecting how code changes relate across local sources.

You can connect Git repositories and ordinary folders in the same workspace. The scanner runs locally, and a GitHub account is not required to analyze your sources.

Try the sample-data demo · Source code

How the folder baseline works

For a configured folder, the scanner discovers supported source files within its scan limits and records each readable file's content hash and line count.

The first scan establishes a baseline. A later scan compares that state with the previous one:

a new path is an added file;
a changed hash is a modified file;
a missing path is a deleted file.

Those file changes feed the existing static evidence graph and scan history. The graph can connect supported API patterns, handlers, callers, database access, documentation, and tests, with evidence available for inspection.

The implementation is in scripts/scan-repos.mjs, including scanFolder, buildFolderFileState, and compareFolderFileState. A synthetic regression fixture checks an initial baseline followed by file creation, modification, and deletion.

Connect a folder

Where am I requires Node.js 22.13 or newer. After following the README setup, add a source folder to whereami.config.json:

{
  "folders": [
    {
      "name": "sample-service",
      "path": "/absolute/path/to/sample-service"
    }
  ],
  "autoFetch": false
}

Run npm run dev for the UI and local watcher, or npm run scan for a single scan. The initial folder scan reports a baseline; edit a supported file and rescan to inspect the change.

What the current baseline cannot tell you

The baseline advances with each scan. It stores hashes and line counts rather than old source text, so it cannot yet show a complete before-and-after line diff for a modified folder file. A same-length edit is detected through its changed hash, but its precise added and deleted lines need further work.

Static extraction is also approximate. Dynamic calls can be missed, and similar symbols or paths can produce incorrect relationships. Inspect the evidence and use tests and engineering judgment when reviewing a change.

Help improve the scanner

I have organized 64 scoped contributor tasks, each with a starting location, acceptance criteria, difficulty, and prerequisite links.

Smaller starting points include configuration diagnostics, making scan omissions visible, graph filters, and extractor fixture documentation.

Deeper work includes persistent folder checkpoints, incremental extraction, scope-aware JS/TS analysis, OpenAPI comparison, and new framework extractors. These are contribution candidates, not shipped capabilities.

If you try it, which missing connection would make it useful in your codebase? A small public or synthetic example of a false link or missed dependency is especially helpful.

Comment on an issue to discuss or claim a task. PR titles and descriptions must be written by the contributor in their own words; see CONTRIBUTING.md.

Disclosure: This post was prepared with AI assistance. The feature descriptions were checked against the repository; the public demo uses sample data.

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

soil0119 — Sun, 13 Sep 2026 10:04:41 +0000

A small API change rarely stays small.

In a multi-repository system, changing one route can affect a frontend wrapper, a backend handler, an internal service, a database call, documentation, and tests. I kept tracing those paths manually, so I built Where am I: an MIT-licensed, local-first tool that turns changes in local Git repositories and ordinary folders into a clickable impact graph using static source evidence.

Repository: github.com/soil0119/Where-am-i

Try the sample-data demo · Choose a contribution task

Where am I is an early MVP. Its output is supporting evidence for review, not a replacement for tests, security checks, or engineering judgment.

The problem I wanted to solve

Most code search tools answer questions about one symbol or one repository. The question I usually had was broader:

If I change this endpoint, where does the change flow across the whole system?

The answer might cross several boundaries:

frontend action
  -> API wrapper
  -> backend route
  -> handler or service
  -> database / external API
  -> OpenAPI docs
  -> tests

A plain dependency graph is not enough. During review I also need to know why two nodes are connected, which line created the relationship, and whether the node belongs to my current work or to an incoming team change.

Design goals

I started with four constraints:

Local-first: configured source repositories should not be uploaded to a hosted analysis service.
Evidence over mystery: every useful connection should lead back to a file and, when available, a source line.
Change-aware: the graph should prioritize the current diff and teammate updates instead of showing the entire codebase at once.
Bounded work: large repositories need explicit scan limits so the tool remains usable during development.

From Git state to an evidence graph

The scanner is a Node.js script. For each configured repository it collects several views of change:

working-tree and staged changes
commits on the current branch compared with its base reference
changes available from the selected remote/base reference

It then combines changed files with priority files and API catalog files. This keeps the first pass focused while still allowing it to connect a changed implementation to contracts, wrappers, documentation, and tests.

At a high level, the pipeline looks like this:

Git repositories
  -> discover repos and base refs
  -> collect diffs and status
  -> extract static facts
  -> connect facts with evidence
  -> write a local snapshot
  -> render an interactive graph

The current extractors recognize patterns such as:

functions and call relationships
API paths, frontend wrappers, and backend handlers
database access and external HTTP requests
OpenAPI documents, documentation, and tests
application error codes

For example, the test fixture includes a frontend fetch("/api/models"), a Go route registered with r.Post("/api/models", createModel), a database call, an external training request, and a Python error code. The test asserts that the generated graph contains handler, database, external-call, and error nodes together with relationship labels and the original evidence lines.

That test matters because a visually convincing graph can still be wrong. I want the graph model—not only the UI—to be testable.

Configuration stays explicit

A minimal configuration can discover repositories under a workspace directory:

{
  "repoRoots": ["/absolute/path/to/your/workspace"],
  "include": ["your-repo-prefix"],
  "baseBranch": "develop",
  "autoFetch": true,
  "liveWatch": true
}

Repositories can also be listed individually. Scan limits cover the number of files, API catalog files, changed files, facts, edges, and nodes included in a scenario. The defaults are intentionally configurable because a useful limit for a small service is not necessarily useful for a monorepo.

If network access is undesirable, autoFetch can be disabled or the scanner can run with --no-fetch.

Track source folders without Git

You can connect an ordinary source folder without creating a Git repository or connecting a GitHub account:

{
  "folders": [
    {
      "name": "sample-service",
      "path": "/absolute/path/to/sample-service"
    }
  ],
  "autoFetch": false
}

The first scan records a local file baseline. Later scans compare content hashes and line counts to detect added, modified, and deleted files, then feed those changes into the existing evidence graph and scan history. Git repositories and plain folders can be analyzed together.

The folder baseline advances with each scan. It currently stores hashes and line counts, not the original source text, so a modified folder file does not yet have a full before-and-after line diff. Persistent checkpoints and more accurate folder diffs are separate contribution tasks.

The UI is a review surface

The interface uses React and XYFlow. It provides separate perspectives for current work, team changes, and API contracts. Search and filters can narrow the graph to changed impact or items that need review.

Selecting a node or edge opens the supporting details: source evidence, representative diffs, relationship rules, change briefings, and suggested next checks. The interface is available in English and Korean; the language choice is stored locally in the browser.

The goal is not to produce the largest possible graph. It is to make the next review question easier to answer.

Local-first does not mean risk-free

The scanner reads the source code in the repositories you configure. Its local configuration and generated snapshot may contain absolute paths, repository names, branches, commit messages, pull request titles, function names, API paths, and evidence lines.

Both files are ignored by Git by default. Production builds remove the local snapshot and show bundled sample data. I still recommend reviewing screenshots and exported output before sharing them, because local analysis can surface information that was never meant to be public.

Current limitations

Static extraction is deliberately pragmatic, so it can miss dynamic calls, reflection, generated code, or complex metaprogramming. Coverage also varies by language and framework. A connection in the graph is evidence worth inspecting, not proof that every runtime dependency has been found.

The next areas I want to improve are:

language- and framework-specific extractors
confidence and explanation for inferred edges
clearer graph behavior on large systems
better pull-request and branch comparison briefings

Try it locally

You need Node.js 22.13 or newer and at least one local Git repository or ordinary source folder:

git clone https://github.com/soil0119/Where-am-i.git
cd Where-am-i
npm install
cp whereami.config.example.json whereami.config.json
npm run dev

The README includes a PowerShell equivalent and the full configuration options.

I would especially value feedback on three questions:

Which language or framework extractor would make this useful for your codebase?
What evidence would you need before trusting an inferred connection?
At what graph size does this kind of view stop helping and start becoming noise?

Because this is an open-source project, please feel free to open a GitHub issue for bugs, feature requests, extractor ideas, documentation gaps, or questions—even if you are not ready to contribute code. Issues and contributions are welcome in English or Korean.

Choose a scoped contribution

I have organized 64 focused contribution tasks, with starting code locations, acceptance criteria, difficulty labels, and prerequisite links.

Smaller tasks include configuration diagnostics, scan-limit visibility, graph filters, and extractor fixture documentation. Deeper work includes scope-aware JS/TS analysis, method-aware API matching, structured OpenAPI comparison, incremental scans, and new framework extractors. These are planned contributions, not a list of implemented features.

Comment on an issue to discuss or claim a task. PR titles and descriptions must be written by the contributor in their own words, with actual verification results; see CONTRIBUTING.md.

Disclosure: I used an AI assistant to draft and edit this post. The implementation details and technical claims were checked against the linked repository.