CodeDiag

codediag

Which of your API routes can anyone call?

Auth and validation coverage for Next.js, SvelteKit, React Router, Express, Fastify, Hono, Elysia, NestJS, and tRPC, plus security, dependency, test, and structure checks. One command, no account, runs offline.

Install

npx @sabahattink/codediag scan .

That's it. Configuration is optional, no account or server is required, and --no-audit keeps the scan fully offline.

Or install globally — this also puts the codediag command on your PATH, which every other example below assumes:

npm install -g @sabahattink/codediag

Package name note: published as @sabahattink/codediag while ownership

of the legacy codediag name on npm is transferred. The CLI binary is still

codediag after install. A migration announcement will follow if/when the

unscoped name becomes available again.

What it checks

codediag auto-detects your stack and runs 5 analyzers. Every finding has a stable rule ID (rule reference), a severity, a location when one exists, and a suggested fix.

API Health NestJS · Express · Fastify · Hono · Elysia · Next.js · SvelteKit · React Router · tRPC

AST analysis (ts-morph, not regex) of the routes your app actually exposes.

• NestJS: auth guards, including global guards (useGlobalGuards, APP_GUARD), custom UseGuards-based decorators, and @Public()-style opt-outs; DTO classes for request bodies (not any, Record, or interfaces) and whether a ValidationPipe enforces them; Swagger docs and return types.
• Express: routers resolved from express(), Router(), and typed parameters; auth and validation middleware on routes, earlier router.use() calls, and app.use(path, mw, router) mounts across files; centralized error handling and health endpoints.
• Fastify: routes from fastify.get() and fastify.route(), followed through register()-ed plugins, fastify-plugin encapsulation, and @fastify/autoload directories (directory prefixes, autoPrefix, and autohooks, as fastify-cli projects use them); onRequest/preHandler auth hooks on the route or its context, body schemas on mutating routes, setErrorHandler, and health endpoints.
• Hono: routes on new Hono() apps, basePath(), and sub-apps mounted with app.route() across files, replayed in registration order; auth middleware (jwt(), bearerAuth(), basicAuth(), or your own) on the route or an earlier matching app.use(); zValidator and other body validators; onError; and health endpoints.
• Elysia: routes on new Elysia() instances, prefix, group(), and plugins mounted with use() across files, functional plugins included, replayed in registration order with Elysia's hook scope: a plugin's hooks reach the instance that uses it only when they are scoped or global ({ as: 'scoped' }, .as('scoped')). Auth from onBeforeHandle(), a derive() or resolve() that rejects with 401, guard(), auth macros such as better-auth's { auth: true }, onRequest(), or a check in the handler; when a route misses an auth hook that exists, the finding says whether the hook stayed local to its plugin or came after the route. Body schemas (TypeBox, Zod, or another Standard Schema) in the route options or a guard(); onError; and health endpoints.
• Next.js: App Router and Pages Router API handlers, without penalizing frontend-only projects. Middleware (proxy.ts in Next.js 16) protects a route only if it turns an anonymous request to that path away: its matcher, pathname checks, next-auth, Clerk's protect(), Auth.js authorized callbacks, and helpers it returns, such as Supabase's updateSession(), are evaluated for each route.
• SvelteKit: +server endpoints and form actions, with route ids from src/routes; auth in the handle hook (through sequence() and path or route id guards) or in the handler and the helpers it calls; a note when the only auth check sits in a layout load, which never runs for actions and endpoints; body validation; and CSRF origin checks turned off in svelte.config.js.
• React Router and Remix: actions and loaders from app/routes.ts or Remix v2 flat-route files; auth in the action, its helpers, or route middleware; a separate rule when a parent's or the route's own loader holds the only auth check, since neither runs before an action; and schema validation of form and JSON bodies.
• tRPC: procedures resolved from initTRPC through builder chains, exported builders such as protectedProcedure, and nested or merged routers across files (including ~/ path aliases); mutations without auth middleware (judged by what the middleware checks, not its name), .input() parsers that accept anything, and error formatters or isDev: true that expose stack traces. Auth in front of every procedure counts too: a createContext that rejects anonymous callers, auth middleware ahead of the Express or Hono mount, an auth hook over the Fastify plugin, or a Next.js middleware.ts (proxy.ts in Next.js 16), Auth.js included, that rejects anonymous requests to the tRPC route. The checks run inside whichever server hosts tRPC (T3/Next.js, Express, Fastify, Hono, Elysia, SvelteKit), and a standalone tRPC server is its own stack. An intentionally public mutation, such as sign-up, is accepted with a reasoned codediag-ignore-next-line directive.

Security

Hardcoded credentials, .env protection in .gitignore, Helmet, rate limiting, open CORS, weak password hashing, and direct password comparisons. Runtime sinks (eval, new Function, shell commands, raw SQL, disabled TLS verification) are found in the AST, and request data is traced through variables, destructuring, reassignments, and up to two calls into your own helper functions and services, so const cmd = req.query.cmd; exec(cmd) is critical, and so is run(req.query.cmd) when run calls exec in another file. Request data is also followed into fields a class stores it in, through constructors, into map/forEach callbacks and for...of loops, and to NestJS providers behind an interface or injection token. tRPC procedure input is request data too, even after .input(schema) validates it. Request data that reaches a file path, an outgoing request's host, a redirect, or an HTML response is reported as path traversal, SSRF, an open redirect, or reflected XSS; request data compiled as a template or used as an object path is template injection or prototype pollution. JWT options that accept none or ignore expiration, and session cookies without httpOnly/secure, are flagged too. Secrets are also looked for in JSON, YAML, Dockerfiles, .npmrc, and .env files that Git tracks, and no report ever contains the value. With --secret-history (or secretHistory in .codediag.yml), the lines recent commits added are also searched for credentials that were committed and later deleted, which every clone still contains (secret-in-git-history); it is off by default because results depend on clone depth. In Supabase projects, supabase/migrations is replayed in order and tables the API exposes without row level security are critical (supabase-table-without-rls), as are write policies whose using or with check is true (supabase-permissive-policy). See Security analysis.

Dependencies

Runs the matching npm, pnpm, Yarn Classic, or Yarn Berry audit (skipped with --no-audit; audit: production checks only the dependencies you ship), names the affected packages and their advisories in each vulnerability finding, checks the lock file and packageManager consistency, flags deprecated packages, and validates engine specs and essential scripts. Monorepo lock files are found up to three parent directories. A successful audit is kept for an hour in node_modules/.cache/codediag, keyed by the lock file and package.json, so repeated scans reuse it (the Dependencies summary says when); delete that directory to force a fresh audit. pnpm audits a whole workspace lock file from any package, so packages that share one run a single audit and each reports only the advisories its own dependencies reach.

Testing

Test files and frameworks (Jest, Vitest, Mocha, Ava, node:test), the test-to-source ratio, integration test directories, and coverage. A coverage-summary.json is measured against 80% lines/statements and 70% functions/branches; otherwise CodeDiag checks for a real coverage threshold in Jest, Vitest, node:test, c8, or nyc configuration.

Structure

README content, lint and format config (also inherited from a workspace root), resolved TypeScript strict mode, NestJS feature modules, and environment templates such as .env.example.

Scoring

Each analyzer scores 0-100. Weighted average determines the grade:

API Health: 25%  ·  Security: 30%  ·  Dependencies: 20%  ·  Testing: 15%  ·  Structure: 10%

Analyzer scores use scoring version 2 by default: every analyzer starts at 100 and each finding subtracts a severity weight (critical 25, warning 8, info 2). Further findings of the same rule cost half the previous one, so a single rule costs at most twice its weight. A finding whose root cause is also reported (for example "no test directory" when there are no tests at all) is downgraded to info, linked with causedBy, and costs nothing. Findings that leave an analyzer with nothing to evaluate, such as a missing package.json, set that analyzer to 0.

Every lost point is listed in scoreBreakdown in JSON output, in the HTML and Markdown reports, and under each analyzer with --verbose. Set scoring: { version: 1 } to keep the previous checks-passed scores for one more release.

CLI

codediag scan .                    # Full report

codediag scan . --format json # JSON (for CI/CD) codediag scan . --format sarif # SARIF 2.1.0 (for code scanning) codediag scan . --format md # Markdown (for PRs) codediag scan . --format svg # SVG score badge codediag scan . --format html > codediag-report.html # Interactive dashboard codediag scan . --format fixes > codediag-fixes.md # Review checklist codediag scan . --format prompt > codediag-prompt.txt # Review-only AI handoff codediag scan . --ci # JSON output + exit code codediag scan . --threshold 80 # Exit 1 below 80 in any output mode codediag scan . --fail-on critical # Exit 1 on any active critical finding codediag scan . --quiet # Score only codediag scan . --verbose # All issues and the score breakdown codediag scan . --no-audit # Offline: skip the package manager audit codediag scan . --update-baseline .codediag-baseline.json # Record accepted findings coded