Investigate adding fallow for dead code and codebase health analysis

[EhabY]

Summary

fallow is a Rust-based codebase analysis tool that detects dead code, circular dependencies, code duplication, and complexity hotspots. It is much faster than Knip (5-41x in benchmarks) and works with zero configuration. It auto-detected our Electron + Vite + Vitest + TypeScript setup out of the box.

Trial run on this repo

I ran npx fallow against the current codebase. It analyzed 213 files in 0.34 seconds and found:

Dead code

• 2 unused files -- .vscode-test.mjs and test/mocks/vscode.runtime.ts
• 5 unused exports -- getEventName, AgentMetadataEventSchema, REMOTE_SSH_EXTENSION_IDS, RemoteSSHLogPortRegex, MockOAuthInterceptor
• 15 unused type exports -- across exec.ts, eventStreamConnection.ts, sshConfig.ts, remote.ts, and others
• 119 unused class members -- mostly in test mock helpers (46 in testHelpers.ts alone), but also 8 in coderApi.ts and 8 in pathResolver.ts

Circular dependencies (2 cycles)

• cliCredentialManager.ts -> cliExec.ts -> cli.ts -> cliCredentialManager.ts (11 files affected)
• A shorter cycle through the same area

Code duplication

• 73 clone groups detected, including repeated patterns in test setup and SSH config handling

Complexity hotspots

• extension.ts:activate -- cognitive complexity 30
• workspacesProvider.ts:getChildren -- cognitive complexity 37
• remote.ts:setup -- cognitive complexity 32

Maintainability

• Overall maintainability index: 91.0 (rated "good")

What would be useful

1. Dead code cleanup -- the unused exports and types are low-hanging fruit. Fallow can auto-fix these with fallow fix --dry-run.
2. CI integration -- fallow has a GitHub Action that can run on PRs with --since main to catch new dead code before it lands.
3. Circular dependency tracking -- the two cycles through cliCredentialManager/cliExec/cli are flagged as the top refactoring targets.

Caveats

• Fallow does syntactic analysis only (no TypeScript type resolution), so some "unused" class members may actually be consumed through interfaces or dynamic access. The test mock findings in particular will need filtering.
• VS Code extension APIs use a lot of convention-based exports (e.g. activate/deactivate) that fallow already handles via its Electron plugin, but edge cases are possible.

Suggested next steps

• Review the unused exports/types and clean up what is genuinely dead
• Decide if fallow should be added as a dev dependency or just run ad-hoc
• Consider adding a pnpm fallow script and/or CI check for new dead code on PRs