RepoPilot

electron / electron

Search electron/electron

GitHub

Code

Understand electron/electron's source layout and find a starting point for your task using the saved repository evidence.

A
Architecture grade
score 100/100
0
Import cycles
lower is better
159
Modules parsed
49 edges
100%
Layeredness
clean-layer ratio

Measured from the parsed import graph, retained from the earlier analysis. Coupling, not a reading order.

How the code fits together

  • default_app3 captured source files in this directory. Its responsibility has not been described in the saved analysis.
  • npm3 captured source files in this directory. Its responsibility has not been described in the saved analysis.
  • lib/browser10 captured source files in this directory. Its responsibility has not been described in the saved analysis.
  • lib/common8 captured source files in this directory. Its responsibility has not been described in the saved analysis.
  • lib/isolated_renderer1 captured source file in this directory. Its responsibility has not been described in the saved analysis.

Files at da4c6886fbfd · captured source folders.

Where to start reading

  1. Repository root
  2. Repository root
  3. Public API candidatename match
  4. Runtime candidatename match

Find files for a task

Change the public API

Start with possible export surfaces, then check their consumers and tests. These suggestions use file names, not verified execution paths.

  • File-name match for this task.

Trace runtime behavior

Start with possible startup or request handlers, then follow the calls for your scenario. These suggestions use file names, not verified execution paths.

  • File-name match for this task.
  • File-name match for this task.
  • File-name match for this task.

Add or update tests

Use a nearby test as a pattern. Read the root manifest or contribution guide for the correct test command. These suggestions use file names, not verified execution paths.

  • File-name match for this task.
  • File-name match for this task.
  • File-name match for this task.

Change build or automation

Inspect the relevant configuration and the commands it runs before changing the workflow. These suggestions use file names, not verified execution paths.

  • File-name match for this task.
  • File-name match for this task.
  • File-name match for this task.

File paths come from a snapshot of up to 500 captured paths; an omitted file may still exist.

  • Public and runtime candidates are based on file names; their exports and execution paths still need checking in source.
  • The file list was refreshed after the written analysis. Subsystem descriptions and suggested changes may describe an older revision.

Import graph details

Modules (7)

Source directories grouped from the import graph. Each links to a per-module page with its files and how it couples to the rest.

Architecture and request flow

Critical modules — by import-graph evidence

Import graph
159 files parsed · 49 internal edges

A file is "critical" when lots of other files in the repo import it. The list is sorted by how many files import each one; the top of the list is the most load-bearing. A flame icon means the file is also one of the most-edited recently — when a critical file changes a lot, bugs there ripple wider, so it's where regressions are most likely.

How the A grade breaks down

Imports flow one direction100%
40/40

What fraction of imports go from application code (likely to change) toward foundation code (more stable). High % means the codebase has clean layers — like a pyramid, not a hairball. Healthy repos are above 85%.

Foundation vs application separationspread = 0.32
30/30

Measures how distinct foundation files (rarely change, lots of files depend on them) are from application files (change often, depend on lots of things). A wider spread (higher σ) means clearer layers; a narrow spread means everything's tangled together at roughly the same level.

No circular imports0 cycles
30/30

A 'cycle' is when file A imports B which imports A again (possibly via more files in between). Cycles make builds slower, refactors harder, and tests trickier. −5 points per cycle found.

List — top 12 most-imported files

Architecture evolution

See how the import graph changed in the last 90 days — grade shift, cycles added/removed, top-file rotation. Heavy compute (~30s on first load), cached for 30 days after.

Possibly-unused modules (15)

Import graph

Nothing else in the repo imports these files, and they don't look like entry points — so they may be dead code. Verify before removing: dynamic imports, re-exports, and framework auto-loading (Next.js routes, plugin/DI registries) aren't tracked by the import graph.

isolatedlib/browser/api/auto-updater/msix-update-win.ts
isolatedlib/browser/api/auto-updater/squirrel-update-win.ts
isolatedlib/browser/api/exports/electron.ts
isolatedlib/browser/api/net-fetch.ts
isolatedlib/browser/api/net-websocket.ts
isolatedlib/browser/guest-view-manager.ts
isolatedlib/browser/guest-window-manager.ts
isolatedlib/browser/init.ts
isolatedlib/browser/ipc-dispatch.ts
isolatedlib/browser/ipc-main-impl.ts
isolatedlib/browser/ipc-main-internal-utils.ts
isolatedlib/browser/ipc-main-internal.ts
isolatedlib/browser/parse-features-string.ts
isolatedlib/browser/rpc-server.ts
isolatedlib/browser/web-view-events.ts

Architecture overview

Stack: Node.js runtime + Chromium browser + native platform APIs (Objective-C++ for macOS, C++ for Windows/Linux, shell scripts for build). Patterns: IPC dispatch layer (lib/browser/ipc-dispatch.ts, ipc-main-impl.ts) for message passing between main and renderer processes; module export system through electron.ts gateway; auto-updater abstraction with platform-specific implementations (Windows Squirrel, MSIX, native). Build: TypeScript → JavaScript compilation, node-gyp for native module binding, oxfmt for code formatting.

Code quality and hotspots

Quality Score: 90/100

Low Risk

This repo is in good health with CI, tests, and active maintenance.

High complexity -10

Maintainability grade

Static analysis

How maintainable the code looks — from complexity, code issues, test presence, file size, and hotspot load. It grades the shape of the code, not defect risk, and doesn't replace review.

F
37/100
A ≥ 85, B ≥ 70, C ≥ 55, D ≥ 40, F < 40
Cyclomatic complexityavg 72
0/35
Code issues0 errors, 24 warnings
8/20
Testspresent · ~82% of files
20/20
Largest file2,494 lines
3/15
Hotspot load2 high-risk files
6/10

Configuration status

CI/CD Pipeline — configured

Provider: GitHub Actions

52 GitHub Actions workflows

Test Suite — detected

936 test files detected

Stack: Jest/Vitest

Where: spec

Test Coverage — ~82%heuristic

936 test files / 1,143 source files. This is a file-count ratio, not real line coverage — set up Codecov for authoritative numbers.

Dependency Scanning — no config detected

No Dependabot / Renovate / Snyk / Trivy / CodeQL config found. Enable Dependabot or Renovate.

Live Signals

Real-time data from Codecov, GitHub Actions, GitHub Issues, deps.dev — not estimates.

CI pass rate16%

last 50 runs · median 2s

Stale-issue ratio0%

of 8 recent open issues are 30d+ old with no replies

Maintainer response1h

median first-reply across 15 recent issues · fast

Top hotspots

Files edited often AND hard to reason about. Churn = recent commit frequency, Complexity = branches and nesting, Risk = both combined. These are the highest-leverage targets for refactoring or testing.

api/web-contents.ts
Churn: 76 (19 commits/180d)Complexity: 100Risk: 76
node/asar-fs-wrapper.ts
Churn: 36 (9 commits/180d)Complexity: 100Risk: 36

All hotspots

Files that change often and are complex tend to accumulate more bugs

Code metrics

Static analysis on sampled source files (up to 15 files).

Avg Cyclomatic Complexity72

Counts if/for/while/switch/catch/ternary branches

Errors / Warnings0 / 24

Secrets, empty catches, console.log, var usage, long lines

Largest File Analyzed2494 lines
lib/node/asar-fs-wrapper.ts