Component-level code analysis

A repository-wide number answers "how is this repository doing?". Teams usually need a narrower question answered: "how is the part I own doing, and who owns the part that isn't?". Component-level analysis splits a project's results by component, so each one has its own issues, debt, trend and owner.

What it means

A component is a slice of a repository that one team builds and answers for: a service, a package, a library. Component-level analysis reports metrics per component, alongside the repository-wide totals, instead of only the totals.

Why repository-level metrics aren't enough

This part is opinion, from how such numbers tend to behave:

• Averages hide hotspots. A large, healthy package can carry the repository average while a small one next to it accumulates critical issues. The total looks fine; one team's code isn't.
• A number without an owner isn't a task. "412 days of technical debt" doesn't tell anyone where to start. "38 open issues in services/, owned by @checkout" does.
• Trends get blurred. A repository-wide trend mixes every team's work, so an improvement in one area can mask a regression in another.

How Sonda does it

On the Sonda server, a component is a project's top-level directory, or . for files at the repository root. For each component, on any branch, the web app shows:

• its languages, files and lines of code;
• its owner, and every CODEOWNERS owner of its files with how many files each owns;
• its open issues by severity and category, how many are on new code, and its technical debt;
• open issues at the end of each of the last eight weeks, with accepted issues left out;
• its files, with their issues, debt and most severe issue, and the project's other components.

The Components screen lists the components of every project on its main branch, most issues first, filterable by project and owner. Each component links down to its files, and each file to its issues.

Owners come from CODEOWNERS

Sonda reads the repository's CODEOWNERS file the way GitHub does: the first of .github/CODEOWNERS, CODEOWNERS and docs/CODEOWNERS that exists. Patterns use gitignore syntax, and the last matching line wins. A component's owner is the owner of most of its files.

# Last match wins, as on GitHub.
/services/            @acme/checkout
/services/ledger/     @acme/payments
/packages/            @acme/web-platform

With this file, a project with services/, packages/ and scripts/ shows three components. services/ is owned by @acme/checkout if most of its files fall under that line rather than services/ledger/. scripts/ has no owner, which is worth knowing too.

The file comes from the analyzed repository, so Sonda treats it as untrusted input: overlong lines and unparsable patterns are skipped, and the number of rules is capped.

Configuration

There's nothing to configure. Components follow the directory layout, and owners follow CODEOWNERS. What the scan covers still comes from sonda.toml: files excluded with scan.exclude don't appear in any component.

[scan]
exclude = ["**/node_modules/**", "**/dist/**"]

Limitations

• Top-level directories only. Sonda doesn't read monorepo layouts (go.work, Cargo or pnpm workspaces) yet, so services/checkout and services/ledger are one component, services/.
• No dependencies between components. Sonda doesn't record which component uses which.
• No per-component quality gate. The gate judges the whole project. Use CODEOWNERS and the Components screen to route what fails to the right team.
• It needs the server. The CLI reports per file; grouping into components and owners happens when an analysis is uploaded.

Getting started

1. Run the server and sign in.
2. Add a CODEOWNERS file to the repository, if it doesn't have one.
3. Upload an analysis with sonda scan . --upload, or connect the repository so CI does it on every push (GitHub Actions guide).

Then open Components. To keep the new code in each component clean, set up quality gates.