ERR-05: Resolving the tRPC Dead Dependency
ERR-05: Resolving the tRPC Dead Dependency
Release: v0.1.6 | Control: ERR-05 | Category:
err_api
What Was Found
During a dependency audit, three tRPC packages were identified as installed but entirely unused:
@trpc/server@trpc/client@trpc/react-query
These packages are declared in package.json but no corresponding tRPC routers, procedures, context, or middleware exist anywhere in the codebase. The application currently uses a manual fetch-based REST pattern for all API communication.
Why This Matters
Bundle size. Dead dependencies are bundled into production builds unless explicitly tree-shaken. tRPC packages are non-trivial in size and serve no purpose if unused.
Architectural confusion. The presence of tRPC dependencies signals to contributors that tRPC is — or should be — part of the stack. This can lead to new code being written against a pattern that doesn't exist, or time wasted investigating why tRPC isn't wired up.
Maintenance overhead. Unused packages still require version tracking, security auditing, and upgrade management.
Resolution Options
Option A: Remove tRPC (Recommended if staying with REST)
Remove the three packages from package.json and run your package manager's install command to update the lockfile:
# npm
npm uninstall @trpc/server @trpc/client @trpc/react-query
# yarn
yarn remove @trpc/server @trpc/client @trpc/react-query
# pnpm
pnpm remove @trpc/server @trpc/client @trpc/react-query
This keeps the architecture honest — REST stays, and the dependency list accurately reflects what the application actually uses.
Option B: Implement tRPC (Recommended if end-to-end type safety is a goal)
If tRPC was intentionally added in anticipation of adoption, complete the integration:
- Create a tRPC router (e.g.
src/server/trpc/router.ts) with at least one procedure. - Set up a tRPC context and attach it to the server entry point.
- Replace relevant
fetch-based API calls with tRPC client hooks (useQuery,useMutationvia@trpc/react-query). - Document the router structure for contributors.
Guidance for Future Development
Regardless of which path is taken:
- If REST is retained: Do not introduce tRPC assumptions in code comments, architecture docs, or new dependency choices.
- If tRPC is adopted: Ensure all new API endpoints are defined as tRPC procedures rather than standalone REST routes, to avoid a mixed API layer.
Consistency in API layer choice reduces onboarding friction and prevents divergence between how different parts of the platform communicate.