Fallow: a Rust static analyzer that treats dead code as a graph problem

What Fallow actually solves

Fallow targets a specific pain: code that nobody deletes because deletion requires proving a negative. The README puts it directly: most repositories carry code nobody dares to delete, because deleting means proving a negative. Fallow reads the repository as one dependency graph, from import edges to styling tokens, and reports what that graph shows. The tool is for TypeScript and JavaScript projects, including monorepos. It finds unused files, exports, types, enum and class members, and dependencies; circular dependencies and re-export cycles; duplication; complexity hotspots; architecture boundary violations; and design-system styling drift. The audience is engineers who want a gate on pull requests, not just a report. The audit command gives a pass, warn, or fail verdict on changed files, which is a concrete workflow fit.

The mechanism: one graph, no compiler, no AI

Fallow's static analysis works by building a single dependency graph from the entire repository. The README stresses two properties: deterministic findings and typed output contracts. No AI is inside the analyzer, and no TypeScript compiler or Node.js runtime is needed for static analysis. That is a meaningful architectural choice. Most TS analysis tools either wrap the TypeScript compiler or require a Node environment. Fallow is a Rust binary that parses and analyzes directly. The output is stable: the same input produces the same output with stable fingerprints, so re-running to verify an edit is safe. The graph covers import edges and styling tokens, which is how it can report on CSS and CSS-in-JS drift in the same pass. The optional --type-aware pass adds checker-backed TypeScript evidence for exact symbol usage and cross-file private type leaks, but it is slower and opt-in. Without that pass, the analysis is syntactic, which is a trade-off you should know about.

Running it: from zero-install to a configured gate

The quick start is genuinely quick. npx fallow runs the full pipeline with no installation. npx fallow audit gates only what a PR changed. For a devDependency, npm install --save-dev fallow. The npm package ships three launchers: fallow, fallow-lsp, and fallow-mcp, plus a version-matched agent skill, so editor and agent integrations resolve the project-local binary instead of whatever is on PATH. Exit codes are explicit: exit 0 and 1 both mean the run succeeded, with 1 meaning findings; exit 2 is a real error, reported as a JSON envelope on stdout. That contract matters for scripts and CI. Configuration is file-based with a precedence order: .fallowrc.json (JSONC accepted) > .fallowrc.jsonc > fallow.toml > .fallow.toml. First match wins per directory, with no merging. A minimal config just needs an ignorePatterns entry for generated files, as the README shows with **/*.generated.ts. You do not have to write that by hand: npx fallow recommend detects the stack and prints a proposed config, ending with the few subjective choices it will not decide for you. It is read-only and always exits 0.

The audit gate and inherited findings

The audit command is where Fallow differentiates itself from a plain linter. The README gives an excerpt from a run on the vitest monorepo, auditing the last 15 commits. It reported 156 dead code issues, 6 complexity findings, and 8 clone groups across 19 changed files, in 1.05 seconds. But the gate passed because 163 inherited findings were excluded by design. That is a specific mechanism: the audit gate only blocks on findings introduced by the change, not pre-existing ones. You can run with --gate all to enforce everything. This is a sensible default for a PR workflow, but it is also a risk: inherited findings can accumulate silently if nobody ever runs the full gate. The README presents this as a feature, and it is, but it means the audit gate alone will not clean up a legacy codebase. You need a separate effort to address inherited debt.

Similar-code and security: opt-in features with real limits

Fallow includes two opt-in features that go beyond the core graph analysis. The first is similar-code discovery, which finds functions that may share intent despite different syntax. The README is explicit that this uses a pinned local model and requires explicit review. It is not a free-for-all similarity search; it is a candidate generator. The second is security candidates, ranked by reachability from entry points, via fallow security. The README links to a separate verification document, which suggests the security findings are not self-contained and need agent or human verification. Both features are opt-in, which is the right call for a tool that otherwise promises determinism. But the similar-code model is still a model, so the determinism guarantee does not extend to that feature. If you need exact, reproducible similarity results, you should rely on the suffix-array duplication detector instead.

Where Fallow is the wrong tool

Fallow has clear limitations. The README itself points to a limitations page for the boundaries of the default syntactic and optional type-aware analyses. The main failure mode is generated code: the README says generated files usually need a hint via ignorePatterns. Without that, the first run will produce noise. Another limitation is the absence of runtime evidence in the static layer. Dead code detection is based on the dependency graph, not on what actually executes in production. That is exactly what the paid Fallow Runtime layer adds: hot-path review and cold-path deletion evidence from real production traffic. If you need to know whether a function is called in production, the free static analysis cannot tell you. The optional --type-aware pass improves accuracy but is slower, so it is not the default. For very large monorepos, the warm base-snapshot cache mentioned in the benchmark suggests performance is a concern, but the README does not give details on cache invalidation.

Alternatives and the runtime layer

The obvious alternative is the TypeScript compiler itself, or tools built on it like ts-prune or knip. Those tools require a Node environment and often a tsconfig, and they operate on the compiler's type information. Fallow's approach is different: it is a standalone Rust binary that does not need the TypeScript compiler or Node at all. That makes it faster to install and run, but it means the default analysis is syntactic, not type-aware. For exact symbol usage, you need the optional --type-aware pass. Another alternative is a dedicated duplication tool like jscpd, which handles many languages but does not build a full dependency graph or produce a health score. Fallow's edge is the unified graph: one run gives you dead code, duplication, circular deps, complexity, boundaries, and styling drift in a single typed JSON document. The paid Fallow Runtime layer is not an alternative but an extension: it merges production execution evidence into the same reports. The README frames it as static vs runtime, and the decision to pay depends on whether your deletion risk is driven by production traffic or by static reachability.

Maintenance, licensing, and upgrade cost

Fallow is MIT licensed, which is permissive and low-friction for commercial use. The project is actively maintained, with three releases within a week in the provided log: v3.20.0 added Yarn PnP resolution, monorepo tsconfig scope, and review schema 8; v3.19.0 added one-pass agent install, MCP resources, and similar-code discovery; v3.18.0 improved graph accuracy and diagnostics. The release cadence is high, which means you should expect frequent updates. The npm package ships version-matched launchers, so the editor and agent integrations resolve the project-local binary. That reduces the risk of version skew, but it also means you need to update the npm package to get the matching binary. The config schema is versioned (review schema 8), which implies breaking changes are possible. The README mentions a schema.json in the package, so you can validate your config against it. For upgrade cost, the deterministic output and stable fingerprints help, but you should still test the audit gate after a major version bump, especially if you rely on the JSON output contract.

Editorial conclusion

Adopt Fallow if you work in a TypeScript or JavaScript monorepo and need a deterministic, fast, no-AI static analysis gate for pull requests, especially if you want to avoid maintaining a Node or TypeScript toolchain for analysis. Skip it if you need deep type-aware analysis by default (the --type-aware pass is optional and slower), or if you expect runtime evidence without paying for the Fallow Runtime layer. Before adopting, verify how Fallow handles your generated files and framework entry points: run npx fallow recommend, review the proposed config, and test the audit gate on a small PR to confirm the inherited-findings exclusion matches your workflow.

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes