How to Instantly Spot Technical Debt and Architecture Issues in TypeScript/JS: Automated Codebase Audits with fallow

I'm Denis Shokhirev, Agentic AI Systems Architect based in Freiburg, running DennisCraft AI Studio on a Claude, Supabase, n8n, Doppler, and self-hosted Postgres stack. In B2B production environments, I've repeatedly seen supposedly "well-reviewed" TypeScript/JS projects go live with invisible technical debt — cyclic dependencies, dead code, and architectural anti-patterns that manual reviews consistently miss. Automated code audits with fallow have exposed these issues in under 30 minutes, even after months of human review.

Manual Reviews Miss the Big Picture — and Critical Risks

In real-world TypeScript/JS projects, the standard code audit process is a 1–2 day manual review: a senior engineer skims the repo, flags "code smells," and creates a long list of suggestions. The reality:

• Half the comments end up as subjective style notes ("could go either way"),
• Critical vulnerabilities (e.g., SQL injection, mishandling of secrets) often slip through,
• True architectural issues (cyclic dependencies, hidden side effects, anti-patterns) rarely surface without specialized tooling.

On three recent agent deployments, I personally caught the same SQL-injection pattern in auto-generated DB layer code — all of which had "passed" conventional human reviews.

What Is fallow and Why Does It Work for JS/TS?

fallow is an open-source static analysis tool for TypeScript and JavaScript that builds a full dependency graph, highlights dead (unused) code, detects cyclic dependencies, unused entry points, and even architectural anti-patterns. See the project at https://github.com/fallow-land/fallow.

fallow runs locally, never uploads code to the cloud, which is critical for compliance in EU/DACH markets.

Common JS/TS Monolith Issues fallow Surfaces Within Minutes

• Cyclic dependencies between files/modules: block refactoring, break tree-shaking, complicate testing.
• Dead code: leftover modules after migrations that are never actually called.
• Hidden entry points: forgotten endpoints, non-obvious side effects.
• "Feature envy": modules too tightly coupled, violating the Single Responsibility Principle.
• Complex dependency graphs: hard to reason about what impacts core business logic.

In my experience: in production projects older than 2 years, there are always at least 3–5 critical cycles and dozens of dead files waiting to be found.

How to Integrate fallow Into a Real-World TypeScript/JS Project

1. Quick Start — Local Audit

npm install -g @fallow-land/cli
fallow -p ./src --format json --report report.json
cat report.json | jq '.'

The result is a detailed JSON report: dependency graph, all cycles, dead code, orphan modules. In my workflow, this report is shared via Notion or automatically via n8n to Slack.

2. Visualization for Architecture Review

fallow -p ./src --format html --report report.html
open report.html

Visualizing cycles and dead code is not just "nice to have." On one client project, the payments module was still depending on legacy-auth — a business logic violation that only became obvious through fallow's graph.

3. CI/CD Integration and Automated Notification

# .github/workflows/fallow-audit.yml
name: fallow audit
on:
  push:
    branches: [ main ]
jobs:
  fallow-audit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Install Node.js
        uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm ci
      - run: npm install -g @fallow-land/cli
      - run: fallow -p ./src --format json --report report.json
      - uses: actions/upload-artifact@v4
        with:
          name: fallow-report
          path: report.json

Every push to main triggers an automated architectural audit — results are surfaced in PRs or sent to Slack via n8n.

Production Use Cases for fallow

• Regular legacy audits before major releases,
• Codebase assessment during acquisition or outsourcing,
• Auto-checking PRs for introduction of new cycles,
• Summarizing reports for CTO/PM via Claude or GPT integration.

Combining fallow with semgrep (semgrep.dev) covers both architecture and security: semgrep for vulnerabilities, fallow for structural debt. In B2B/fintech, this is essential. For example, BaFin in Germany requires provable change transparency — fallow + a reporting script provides a ready baseline.

FAQ

Can fallow analyze monorepos with multiple packages?

Yes, fallow supports monorepos, but you should run it from the root and specify all relevant entry points.

How does fallow compare to depcruise or ESLint?

depcruise visualizes dependencies, ESLint finds style issues and bugs, but only fallow directly detects dead code and cycles at the architecture level.

How do you handle large reports (500+ files)?

I generate a summary with Claude or GPT: "List the top 5 critical cycles and dead code areas." Don't aim for "perfect" — removing the most dangerous hotspots is enough.

Is there a risk of code leakage when using fallow?

No, fallow runs locally — nothing is sent externally. This is a hard requirement for compliance in the EU and Germany.

Can fallow be integrated with n8n for automation?

Yes, via shell commands and parsing the JSON report. I've set up scheduled Slack and Telegram summaries through n8n.

When was the last time you viewed your JS/TS codebase as an architecture graph, not just by "gut feel"? At which stage in your pipeline do the most critical issues surface — code review or only after production incidents? I run a free 30-min stack audit for DACH founders building AI in regulated markets. DM me on LinkedIn or write to @ger_dennis_ai.