Find Dead Code in a Next.js Project

The agent clones the repository into its own sandbox and maps how Next.js and the monorepo reach code before it trusts any tool's output. In a Next.js codebase like dubinc/dub, the root package.json sets packageManager to pnpm@9.15.9 and runs Turborepo 1 (turbo.json still uses the pipeline key), and pnpm-workspace.yaml covers apps/*, packages/*, packages/embeds/* and apps/web/.react-email. The app is apps/web on Next.js 15.5.8, with Prisma 6.19.1 reading a schema split across files in apps/web/prisma/schema, so build there is pnpm prisma:generate && next build.

In a Next.js app most entry points are files no one imports: every page.tsx, layout.tsx, route.ts, not-found.tsx and opengraph-image.tsx under apps/web/app is loaded by the framework, as are middleware.ts, instrumentation.ts and next.config.js. The agent runs knip with its Next.js plugin enabled for apps/web and adds the entries this repository needs on top. scripts/run.ts starts tsx ./scripts/${command}.ts from a name on the command line, so every file under apps/web/scripts looks unused to static analysis and is marked as an entry. vitest.config.ts loads tests/setupTests.ts, the @/lib/*, @/ui/* and @/scripts/* aliases come from apps/web/tsconfig.json, and packages/email exports ./templates/* as a wildcard, so each of its templates is reachable by name.

Published packages need their own rule. The root scripts publish @dub/ui, @dub/utils, @dub/embed-core, @dub/embed-react, @dub/tailwind-config and the CLI to npm, so an export of one of them that nothing in the monorepo imports may still be used by someone outside it. The agent lists those as public API to decide on, never as dead. It also flags configuration that points at nothing: apps/web/tsconfig.json includes ../../packages/blocks/src/event-list.tsx, and there is no packages/blocks in the repository.

Each remaining candidate is then checked by removing it on a scratch branch and running what would catch the breakage: tsc --noEmit for apps/web and the check-types script in packages/ui and packages/utils, pnpm build in apps/web (Prisma generate and next build), pnpm build:packages for the packages, and next lint. The Vitest suite in apps/web/tests calls a running deployment through E2E_BASE_URL (tests/utils/env.ts), so the agent says plainly that it could not run it in the sandbox rather than reporting it as passed. A dependency is checked by removing it from its workspace's package.json, running pnpm install and the same commands. Anything that fails goes back, with its error, into a list of things that looked dead and were not.

What comes back is dead-code.md, a session artifact with a download link that lasts an hour. It lists what can be removed in three groups, files, exports and dependencies, and for each line names the workspace and the checks that still passed with it gone. A separate section lists exports of the published packages that only outside users could reach, and another lists configuration that refers to paths that no longer exist, such as a tsconfig.json include.

The report is as honest about what it could not prove as about what it did. The checks section says which commands ran on every candidate and which could not run in the sandbox, such as an integration suite that needs a live deployment, so a reader knows exactly what each removal rests on. The session's transcript keeps every knip run and every remove-and-rebuild cycle with its output.

Before deleting, a reviewer looks for code reached in ways neither knip nor the build can see: a helper only a cron route listed in apps/web/vercel.json reaches through a computed import, a template picked by name at runtime, or a script someone runs by hand. Route handlers themselves are entries and never reported, so a cron that is no longer needed is a question for the team, not this report. Then a follow-up message to the same session can ask for a pull request that removes the confirmed items, one group per commit.

Dead code is cheapest to remove right after a release, when nothing is in flight. When your release process cuts a branch, have it send this request from your server with an Idempotency-Key built from the release tag, so each release starts one run.

A webhook URL on the API key gets run.completed with the session_url when the run finishes. Your server reads the session, takes the dead-code.md link from its artifacts and opens a cleanup issue with it attached.

Proving removals in a monorepo this size means many cycles of edit, install, Prisma generate, type check and next build, each one long enough to block a laptop. In a Rush sandbox all of those run on the agent's own machine and disk, with its own node_modules and Prisma client, and your working tree and branches are never touched.

A report that says something is unused has to be believed by people who did not run it. This one carries the transcript of every command and its output, and says outright which checks could not run, so each line can be traced to a passing build. Several repositories, or several workspaces of one, can be checked at once, one run each, up to the key's concurrent run limit.

Does it understand the App Router's file conventions?

What about tests that need secrets or a live deployment?

Will it delete code from my repository?

Does it work with pnpm workspaces and Turborepo?