tRPC architecture: modules, API surface, dependency graph

At a Glance

---

What This System Does

tRPC is a Express command-line tool built with TypeScript, Node.js. It operates as a command-line interface, enabling users to interact with the system through terminal commands. This architecture is optimized for automation, scripting, and integration into CI/CD pipelines.

Business Capabilities

The system is organized around 5 functional domains, each representing a distinct business capability:

Technical Foundation

Module Composition

The codebase follows a layered architecture with clear separation of concerns:

Monorepo Structure

This is a pnpm workspaces monorepo containing 1 packages. This structure enables:

• Independent versioning and deployment of packages
• Shared code reuse across internal projects
• Coordinated development with clear ownership boundaries

Key packages:

• @trpc/server — packages/server

Codebase Health

Overall Health: 🟢 100/100

Key Insights

• ✅ Clean module boundaries — No circular dependencies detected, enabling safe refactoring and testing.
• ✅ Healthy coupling — Most-imported module (packages/server/src/unstable-core-do-not-import/utils) serves 16 files without excessive centralization.

Key Data Flows

The system processes information through 5 identified flows:

• next-app-dir Request Flow — Import chain starting from packages/server/src/adapters/next-app-dir — traces how this entry point depends on 1 downstream module
• express Request Flow — Import chain starting from packages/server/src/adapters/express — traces how this entry point depends on 2 downstream modules
• next Request Flow — Import chain starting from packages/server/src/adapters/next — traces how this entry point depends on 2 downstream modules
• standalone Request Flow — Import chain starting from packages/server/src/adapters/standalone — traces how this entry point depends on 2 downstream modules
• fastify Request Flow — Import chain starting from packages/server/src/adapters/fastify — traces how this entry point depends on 3 downstream modules

Strategic Observations

• The codebase follows Core/kernel architecture — `packages/server/src/unstable-core-do-not-import`, `packages/server/src/unstable-core-do-not-import.ts`; high fan-in, Integration adapters — `packages/server/src/adapters`, Acyclic dependency graph — clean layering architectural patterns, providing a familiar structure for developers.
• With 5 distinct domains, the system has clear separation of concerns suitable for team-based development.
• Strong engineering practices are in place: automated testing and clean dependency boundaries support ongoing development.
• As a CLI tool, this system is automation-friendly and can integrate into existing workflows and pipelines.

---

This executive summary was generated from comprehensive repository analysis including dependency graphs, data flow detection, and architectural pattern recognition. Enable AI enhancement with `GITHUB_TOKEN` for strategic recommendations, risk assessments, and plain-language explanations tailored for non-technical stakeholders.

<!-- repolens:docs-badge -->  · Examples

The Big Picture

tRPC is a focused codebase with a clear purpose, containing 8 modules spread across 73 files.

---

Technology Stack

The system is built on a modern technology foundation:

Architecture Patterns

The codebase follows 3 identified architectural patterns:

• Core/kernel architecture — `packages/server/src/unstable-core-do-not-import`, `packages/server/src/unstable-core-do-not-import.ts`; high fan-in — A structured approach to organizing code and managing complexity.
• Integration adapters — `packages/server/src/adapters` — A structured approach to organizing code and managing complexity.
• Acyclic dependency graph — clean layering — The system operates as a command-line interface, accepting user input through terminal commands and producing structured output.

Module Architecture

The system is organized into 4 architectural layers:

Layer Details

core — 2 modules

• packages/server/src/unstable-core-do-not-import — 40 files — Core application module
• packages/server/src/unstable-core-do-not-import.ts — 1 files — Core application module

integration — 1 module

• packages/server/src/adapters — 23 files — Core application module

Other Modules — 4 modules

• packages/server/src/observable — 5 files — Core application module
• packages/server/src/http.ts — 1 files — Core application module
• packages/server/src/index.ts — 1 files — Core application module
• packages/server/src/rpc.ts — 1 files — Core application module

Shared Libraries — 1 module

• packages/server/src/shared.ts — 1 files — Core application module

Functional Domains

The following domains represent the largest functional areas by file count:

Dependency Graph

Codebase Health: 🟢 100/100

Hub modules (most imported):

• packages/server/src/unstable-core-do-not-import/utils — imported by 16 files
• packages/server/src/unstable-core-do-not-import/error/TRPCError — imported by 8 files
• packages/server/src/unstable-core-do-not-import — imported by 7 files

Monorepo Structure

This is a pnpm workspaces monorepo containing 1 packages:

---

This system overview was generated from comprehensive repository analysis. Enable AI enhancement with `GITHUB_TOKEN` for narrative context, architectural rationale, technology trade-off analysis, and scalability recommendations.

<!-- repolens:docs-badge -->  · Examples

Overview

tRPC is organized into 5 functional domains, each representing a distinct area of business capability. This document maps the technical structure to business-oriented functional areas.

Quick Reference:

---

1. Core Engine

Business Capability

path packages/server/src/unstable-core-do-not-import matches core

This is a significant domain with 2 modules and 41 source files.

Key Modules

Business Impact

• Change Frequency Impact: Medium — Changes here affect 41 files
• Domain Complexity: Simple

---

2. Integrations

Business Capability

path packages/server/src/adapters matches adapter

This is a significant domain with 1 module and 23 source files.

Key Modules

Business Impact

• Change Frequency Impact: Medium — Changes here affect 23 files
• Domain Complexity: Simple

---

3. Other

Business Capability

Uncategorized module

This is a focused domain with 3 modules and 7 source files.

Key Modules

Business Impact

• Change Frequency Impact: Low — Changes here affect 7 files
• Domain Complexity: Moderate

---

4. Search & Discovery

Business Capability

path packages/server/src/index.ts matches index

This is a focused domain with 1 module and 1 source file.

Key Modules

Business Impact

• Change Frequency Impact: Low — Changes here affect 1 file
• Domain Complexity: Simple

---

5. Shared Utilities

Business Capability

path packages/server/src/shared.ts matches shared

This is a focused domain with 1 module and 1 source file.

Key Modules

Business Impact

• Change Frequency Impact: Low — Changes here affect 1 file
• Domain Complexity: Simple

---

Cross-Domain Dependencies

The following modules serve as shared infrastructure across multiple domains:

Cross-Domain Integration Points

These modules facilitate communication and data sharing between domains:

• `packages/server/src/unstable-core-do-not-import/utils` serves as a central integration point, imported by 16 different modules. Changes to this module have wide-ranging impact and should be carefully coordinated.
• `packages/server/src/unstable-core-do-not-import/error/TRPCError` serves as a central integration point, imported by 8 different modules. Changes to this module have wide-ranging impact and should be carefully coordinated.
• `packages/server/src/unstable-core-do-not-import` serves as a central integration point, imported by 7 different modules. Changes to this module have wide-ranging impact and should be carefully coordinated.

Domain Health Summary

---

Domain mapping is based on directory naming conventions and code organization patterns. Enable AI enhancement with `GITHUB_TOKEN` for business-language descriptions, stakeholder impact analysis, strategic recommendations, and cross-domain relationship narratives.

<!-- repolens:docs-badge -->  · Examples

Architectural Philosophy

tRPC follows a Core/kernel architecture — `packages/server/src/unstable-core-do-not-import`, `packages/server/src/unstable-core-do-not-import.ts`; high fan-in architecture with elements of Integration adapters — `packages/server/src/adapters`, Acyclic dependency graph — clean layering.

Pattern Analysis

Core/kernel architecture — `packages/server/src/unstable-core-do-not-import`, `packages/server/src/unstable-core-do-not-import.ts`; high fan-in

A structured approach to organizing code and managing complexity.

Benefits: Structured organization, maintainability, clarity

Integration adapters — `packages/server/src/adapters`

A structured approach to organizing code and managing complexity.

Benefits: Structured organization, maintainability, clarity

Acyclic dependency graph — clean layering

The system operates as a command-line interface, accepting user input through terminal commands and producing structured output.

Benefits: Automation-friendly, scriptable, integrates with CI/CD pipelines

System Layers

The system is organized into 5 functional layers, each encapsulating a distinct area of responsibility:

Module Layers

Modules are classified into 4 architectural roles:

core

Role: Supporting application functionality

integration

Role: Supporting application functionality

Other Modules

Role: General purpose functionality

Shared Libraries

Role: Provides shared utilities and abstractions used across modules

Technology Foundation

Scale & Complexity Analysis

Dependency Health

Architecture Health Score: 🟢 100/100

Architectural Strengths

• Clean module boundaries — No circular dependencies detected. This enables safe refactoring, isolated testing, and clear ownership boundaries.
• Balanced coupling — No single module dominates the import graph. This reduces change risk and enables parallel development.
• Testing infrastructure — Automated testing with Vitest supports confident evolution.

Hub modules (most imported):

• packages/server/src/unstable-core-do-not-import/utils — imported by 16 files
• packages/server/src/unstable-core-do-not-import/error/TRPCError — imported by 8 files
• packages/server/src/unstable-core-do-not-import — imported by 7 files

Monorepo Architecture

This project uses a pnpm workspaces monorepo with 1 packages.

Package Structure

Monorepo Benefits

• Shared infrastructure — Common tooling and configurations
• Atomic changes — Cross-package updates in single commits
• Independent deployment — Each package can be released separately
• Clear ownership — Package boundaries define team responsibilities

---

This architecture overview was generated from comprehensive dependency graph analysis and pattern detection. Enable AI enhancement with `GITHUB_TOKEN` for architectural narratives, design rationale explanations, scalability analysis, and refactoring recommendations.

<!-- repolens:docs-badge -->  · Examples

A complete inventory of all code modules in the repository, organized by location and size. Each module represents a distinct area of responsibility within the codebase.

Total modules: 8

---

Module Inventory

---

Module detection is based on the `module_roots` setting in your RepoLens configuration. Adjust this setting to change how modules are grouped.

<!-- repolens:docs-badge -->  · Examples

A complete listing of user-facing pages and backend API endpoints. This map shows every URL a user or client can interact with, along with the source file that handles each route.

---

Route Detection

This project is a CLI tool — it does not expose HTTP routes or serve web pages. This is expected behavior, not a detection failure.

CLI tools interact through terminal commands rather than URLs. See the System Overview or Developer Onboarding documents for command documentation.

<!-- repolens:docs-badge -->  · Examples

This page documents both the API endpoints the application exposes and the external services it integrates with. Use it as a reference for understanding the system's interfaces.

---

Internal API Endpoints

These are the backend services the application provides to handle incoming requests.

No API routes were detected in this scan. If your project uses a routing framework (Express, Fastify, NestJS, etc.), ensure the relevant directories are included in your scan.include patterns.

---

External API Integrations

Third-party services the application connects to, grouped by category.

No external API integrations were detected. This section populates automatically when RepoLens identifies SDK imports or API client usage in your codebase.

---

Documented Exports

Exported functions with JSDoc/TSDoc documentation. Documentation coverage: 47%

Function Documentation

packages/server/src/adapters/ws.ts

`handleKeepAlive()`

Handle WebSocket keep-alive messages

packages/server/src/adapters/next-app-dir/redirect.ts

`redirect()`

Like next/navigation's redirect() but throws a TRPCError that later will be handled by Next.js This provides better typesafety than the next/navigation's redirect() since the action continues to execute on the frontend even if Next's redirect() has a return type of never.

packages/server/src/adapters/next-app-dir/rethrowNextErrors.ts

`rethrowNextErrors()`

Rethrow errors that should be handled by Next.js

packages/server/src/adapters/node-http/incomingMessageToRequest.ts

`incomingMessageToRequest()`

Convert an `IncomingMessage` to a `Request`

packages/server/src/adapters/node-http/writeResponse.ts

`writeResponseBody()`

`writeResponse()`

packages/server/src/observable/observable.ts

`isObservable()`

packages/server/src/unstable-core-do-not-import/middleware.ts

`createErrorFormatterMiddleware()`

packages/server/src/unstable-core-do-not-import/rootConfig.ts

`isDevDefault()`

The default check to see if we're in development

packages/server/src/unstable-core-do-not-import/router.ts

`getProcedureAtPath()`

`callProcedure()`

packages/server/src/unstable-core-do-not-import/transformer.ts

`getDataTransformer()`

packages/server/src/unstable-core-do-not-import/utils.ts

`isObject()`

Check that value is object

`assert()`

Generic runtime assertion function. Throws, if the condition is not true. Can be used as a slightly less dangerous variant of type assertions. Code mistakes would be revealed at runtime then (hopefully during testing).

`abortSignalsAnyPonyfill()`

Ponyfill for `AbortSignal.any`.

packages/server/src/unstable-core-do-not-import/error/formatter.ts

`getDefaultErrorShape()`

`setFormattedErrorShape()`

`getFormattedErrorShape()`

packages/server/src/unstable-core-do-not-import/rpc/parseTRPCMessage.ts

`parseTRPCMessage()`

packages/server/src/unstable-core-do-not-import/stream/jsonl.ts

`jsonlStreamProducer()`

JSON Lines stream producer

---

Documentation Summary:

• Total exports: 43
• Documented: 20
• Undocumented: 23
• Coverage: 47%

---

HTTP method reference — GET: retrieve data, POST: create, PUT/PATCH: update, DELETE: remove.

<!-- repolens:docs-badge -->  · Examples

Understanding Data Movement

Data flows describe how information moves through tRPC — from external inputs through processing layers to storage or presentation. Understanding these flows is essential for debugging, performance optimization, and architectural decisions.

Flow Summary

5 data flows identified in the codebase:

---

1. next-app-dir Request Flow

Description

Import chain starting from packages/server/src/adapters/next-app-dir — traces how this entry point depends on 1 downstream module

Characteristics

Processing Steps

Flow Diagram

┌─ START ─┐
│ `next-app-dir` (entry point, imports 4 modules)    │
│         ↓
│ `redirect` (leaf — no further dependencies)        │
└─ END ───┘

Involved Modules

Insights

• Standard integration flow with 2 processing steps

---

2. express Request Flow

Description

Import chain starting from packages/server/src/adapters/express — traces how this entry point depends on 2 downstream modules

Characteristics

Processing Steps

Flow Diagram

┌─ START ─┐
│ `express` (entry point, imports 2 modules)         │
│         ↓
│ `unstable-core-do-not-import` (shared infrastru... │
│         ↓
│ `utils` (shared infrastructure, used by 16 files)  │
└─ END ───┘

Involved Modules

Insights

• Standard integration flow with 3 processing steps

---

3. next Request Flow

Description

Import chain starting from packages/server/src/adapters/next — traces how this entry point depends on 2 downstream modules

Characteristics

Processing Steps

Flow Diagram

┌─ START ─┐
│ `next` (entry point, imports 2 modules)            │
│         ↓
│ `unstable-core-do-not-import` (shared infrastru... │
│         ↓
│ `utils` (shared infrastructure, used by 16 files)  │
└─ END ───┘

Involved Modules

Insights

• Standard integration flow with 3 processing steps

---

4. standalone Request Flow

Description

Import chain starting from packages/server/src/adapters/standalone — traces how this entry point depends on 2 downstream modules

Characteristics

Processing Steps

Flow Diagram

┌─ START ─┐
│ `standalone` (entry point, imports 2 modules)      │
│         ↓
│ `unstable-core-do-not-import` (shared infrastru... │
│         ↓
│ `utils` (shared infrastructure, used by 16 files)  │
└─ END ───┘

Involved Modules

Insights

• Standard integration flow with 3 processing steps

---

5. fastify Request Flow

Description

Import chain starting from packages/server/src/adapters/fastify — traces how this entry point depends on 3 downstream modules

Characteristics

Processing Steps

Flow Diagram

┌─ START ─┐
│ `fastify` (entry point, imports 2 modules)         │
│         ↓
│ `fastifyRequestHandler` → imports 1 module         │
│         ↓
│ `node-http` (shared infrastructure, used by 5 f... │
│         ↓
│ `incomingMessageToRequest` (leaf — no further d... │
└─ END ───┘

Involved Modules

Insights

• Standard integration flow with 4 processing steps

---

Import Network

The system has 146 internal import edges connecting 73 source files.

Network Topology

Key Integration Points

These modules aggregate data from multiple sources:

---

Flow detection uses naming conventions, import patterns, and dependency graph analysis. Enable AI enhancement with `GITHUB_TOKEN` for end-to-end flow narratives, failure mode analysis, data transformation descriptions, and performance bottleneck identification.

<!-- repolens:docs-badge -->  · Examples

No changes detected.

<!-- repolens:docs-badge -->  · Examples

What is this? This visual diagram shows how different parts of your codebase connect to each other. Arrows indicate dependencies (which modules use which).

Showing: 8 modules and 6 relationships

Source: Real import analysis

---

Architecture Diagram

┌─────────────────────────────────────────────────────────────┐
│              🏗️  SYSTEM ARCHITECTURE MAP                    │
└─────────────────────────────────────────────────────────────┘

⚙️  CORE LOGIC
│
├── unstable-core-do-not-import (40 files)
│      → unstable-core-do-not-import.ts
└── unstable-core-do-not-import.ts (1 file)
       → observable
│
🔌  INTEGRATION
│
└── adapters (23 files)
       → unstable-core-do-not-import
       → http.ts
       → observable
       ... +1 more
│
📦  OTHER
│
├── observable (5 files)
├── http.ts (1 file)
├── index.ts (1 file)
├── rpc.ts (1 file)
└── shared.ts (1 file)
│

Legend:
  →  imports / depends on
  ╌→ tests

---

Key Connections

Most depended-on modules (highest import count):

Most dependent modules (highest dependency count):

<!-- repolens:docs-badge -->  · Examples

Welcome to tRPC! 👋

This guide will help you get up to speed quickly. tRPC is a Express project built with TypeScript, Node.js, containing 8 modules across 73 files.

What You'll Learn

1. ✅ Repository structure and organization
2. ✅ Technology stack and tools
3. ✅ Key modules to understand first
4. ✅ How data flows through the system
5. ✅ How to start contributing

---

Quick Reference Card

---

Repository Structure

Understanding the directory layout is your first step to navigating the codebase:

Where to Begin

Focus on these directories first:

1. `packages/server/src` — Project files

---

Monorepo Navigation

This is a pnpm workspaces monorepo with 1 packages. Here's how to navigate:

Pro tip: Each package can typically be developed independently. Check the package's own README.md for specific setup instructions.

---

Technology Stack

---

Core Modules to Understand

These are the most important modules by size and centrality. Understanding them will unlock the rest of the codebase:

Key Integration Points

These modules are imported by many other files. Changes here have wide impact:

• `packages/server/src/unstable-core-do-not-import/utils` — Used by 16 files — Utility and helper functions
• `packages/server/src/unstable-core-do-not-import/error/TRPCError` — Used by 8 files — Core application module
• `packages/server/src/unstable-core-do-not-import` — Used by 7 files — Core application module

⚠️ Caution: Be extra careful when modifying these files. Consider the ripple effects.

---

How Data Flows

Understanding these flows helps you see how the system processes information end-to-end:

Debugging tip: When investigating issues, trace the data flow from input to output to identify where problems occur.

---

Getting Started Checklist

Follow these steps to set up your development environment:

1. Clone and Install

git clone <repository-url>
cd trpc
npm install  # or yarn, pnpm

2. Explore the Structure

• Review the directory structure above
• Open the README.md for project-specific instructions
• Look for CONTRIBUTING.md for contribution guidelines

3. Understand Core Modules

Start with the high-priority modules listed above. Read the code and comments to understand:

• What problem each module solves
• How modules interact with each other
• What data structures are used

4. Run the Tests

npm test  # or: npx vitest run

Running tests helps you:

• Verify your setup is correct
• See expected behavior documented in test cases
• Understand module interfaces through test examples

5. Make Your First Change

Start small:

1. Find a small bug or typo to fix
2. Make the change in a feature branch
3. Run tests to ensure nothing breaks
4. Submit a pull request for review

---

Common Pitfalls

New contributors often run into these issues:

• Monorepo boundaries — Remember to build dependent packages when making changes.
• Environment setup — Check for .env.example files and ensure you have all required environment variables.
• Branch naming — Follow the team's branch naming conventions (usually feature/, fix/, docs/).

---

Additional Resources

---

This onboarding guide was generated from comprehensive repository analysis. Enable AI enhancement with `GITHUB_TOKEN` for narrative walkthroughs, common pitfall documentation, debugging tips, architecture deep-dives, and personalized contribution recommendations.

Welcome to the team! Happy coding! 🚀

<!-- repolens:docs-badge -->  · Examples

No GraphQL schema was detected in this repository.

RepoLens scans for .graphql and .gql schema files, inline SDL via tagged template literals (e.g. gql\...\``), resolver patterns, and popular GraphQL libraries including Apollo, Yoga, Nexus, Pothos, Mercurius, type-graphql, Relay, and urql.

If your project uses GraphQL, ensure the relevant source directories are included in your scan.include configuration.

<!-- repolens:docs-badge -->  · Examples

43 file(s) with type declarations · 29 interface(s) · 231 type alias(es) · 6 class(es) · 185 relationship(s)

This document maps the type system of the project, showing how interfaces, classes, and type aliases relate to one another. Understanding these relationships helps navigate the codebase and identify coupling between modules.

Interfaces

29 interfaces define the data contracts used across the application:

Classes

6 classes provide concrete implementations:

Type Aliases

231 type aliases define computed or composite types:

Type Relationships

The following diagram shows inheritance, implementation, and reference relationships between types:

AWSLambdaOptions
  ├── uses → AnyRouter
  └── uses → AWSLambdaCreateContextFn
AWSLambdaCreateContextFn
  └── uses → CreateAWSLambdaContextOptions
CreateExpressContextOptions
  └── uses → NodeHTTPCreateContextFnOptions
CreateNextContextOptions
  └── uses → NodeHTTPCreateContextFnOptions
StandaloneHandlerOptions
  └── uses → NodeHTTPHandlerOptions
CreateHTTPHandlerOptions
  └── uses → StandaloneHandlerOptions
CreateHTTPContextOptions
  └── uses → NodeHTTPCreateContextFnOptions
CreateHTTP2HandlerOptions
  └── uses → StandaloneHandlerOptions
CreateHTTP2ContextOptions
  └── uses → NodeHTTPCreateContextFnOptions
CreateWSSContextFnOptions
  └── uses → NodeHTTPCreateContextFnOptions
CreateWSSContextFn
  ├── uses → CreateWSSContextFnOptions
  └── uses → MaybePromise
WSConnectionHandlerOptions
  └── uses → CreateWSSContextFn
WSSHandlerOptions
  └── uses → WSConnectionHandlerOptions
ContextResult
  ├── uses → Result
  └── uses → Context
FastifyHandlerOptions
  └── uses → NodeHTTPCreateContextOption
FastifyRequestHandlerOptions
  └── uses → FastifyHandlerOptions
CreateFastifyContextOptions
  └── uses → NodeHTTPCreateContextFnOptions
FetchCreateContextFn
  └── uses → FetchCreateContextFnOptions
FetchCreateContextOption
  └── uses → FetchCreateContextFn
FetchHandlerOptions
  └── uses → FetchCreateContextOption
FetchHandlerRequestOptions
  └── uses → FetchCreateContextFn
TRPCRedirectError
  └── extends → TRPCError
NodeHTTPRequest
  └── uses → DistributiveOmit
NodeHTTPResponse
  └── uses → DistributiveOmit
NodeHTTPCreateContextOption
  └── uses → NodeHTTPCreateContextFn
NodeHTTPHandlerOptions
  └── uses → ConnectMiddleware
NodeHTTPRequestHandlerOptions
  └── uses → NodeHTTPHandlerOptions
NodeHTTPCreateContextFn
  ├── uses → NodeHTTPCreateContextFnOptions
  └── uses → MaybePromise
TeardownLogic
  ├── uses → Unsubscribable
  └── uses → UnsubscribeFn
OperatorFunction
  └── uses → UnaryFunction
MonoTypeOperatorFunction
  └── uses → OperatorFunction
inferTransformedProcedureOutput
  └── uses → Serialize
inferTransformedSubscriptionOutput
  └── uses → Serialize
GetInferenceHelpers
  ├── uses → AnyProcedure
  └── uses → RouterRecord
inferRouterInputs
  └── uses → GetInferenceHelpers
inferRouterOutputs
  └── uses → GetInferenceHelpers
AnyClientTypes
  └── uses → AnyRootTypes
InitLike
  └── uses → AnyClientTypes
RouterLike
  └── uses → InitLike
RootConfigLike
  └── uses → AnyClientTypes
InferrableClientTypes
  ├── uses → RouterLike
  ├── uses → InitLike
  ├── uses → RootConfigLike
  └── uses → AnyClientTypes
inferClientTypes
  ├── uses → AnyClientTypes
  ├── uses → PickTypes
  ├── uses → RootConfigLike
  ├── uses → InitLike
  └── uses → RouterLike
JsonArray
  └── uses → JsonValue
JsonObject
  └── uses → JsonValue
JsonValue
  ├── uses → JsonPrimitive
  ├── uses → JsonObject
  └── uses → JsonArray
IsJson
  └── uses → JsonValue
JsonReturnable
  └── uses → JsonPrimitive
IsRecord
  └── uses → WithoutIndexSignature
Serialize
  ├── uses → IsAny
  ├── uses → IsJson
  ├── uses → JsonReturnable
  ├── uses → NonJsonPrimitive
  ├── uses → SerializeTuple
  ├── uses → IsRecord
  ├── uses → SerializeRecord
  ├── uses → Simplify
  ├── uses → SerializeObject
  └── uses → UndefinedToOptional
SerializeRecord
  └── uses → Serialize
SerializeTuple
  ├── uses → NonJsonPrimitive
  └── uses → Serialize
SerializeObject
  └── uses → Serialize
HandleIndexSignature
  └── uses → WithoutIndexSignature
HandleUndefined
  └── uses → FilterDefinedKeys
UndefinedToOptional
  ├── uses → WithoutIndexSignature
  ├── uses → FilterDefinedKeys
  ├── uses → ExactOptionalPropertyTypes
  ├── uses → HandleIndexSignature
  ├── uses → HandleUndefined
  └── uses → HasIndexSignature
ProxyCallback
  └── uses → ProxyCallbackOptions
inferErrorFormatterShape
  ├── uses → ErrorFormatter
  └── uses → DefaultErrorShape
MiddlewareFunction
  ├── uses → Simplify
  └── uses → Overwrite
AnyMiddlewareFunction
  └── uses → MiddlewareFunction
ParserWithoutInput
  ├── uses → ParserCustomValidatorEsque
  ├── uses → ParserMyZodEsque
  ├── uses → ParserScaleEsque
  ├── uses → ParserSuperstructEsque
  └── uses → ParserYupEsque
ParserWithInputOutput
  ├── uses → ParserZodEsque
  ├── uses → ParserValibotEsque
  ├── uses → ParserArkTypeEsque
  └── uses → ParserStandardSchemaEsque
Parser
  ├── uses → ParserWithInputOutput
  └── uses → ParserWithoutInput
inferParser
  └── uses → ParserStandardSchemaEsque
AnyProcedure
  ├── uses → AnyQueryProcedure
  ├── uses → AnyMutationProcedure
  └── uses → AnySubscriptionProcedure
inferProcedureParams
  └── uses → AnyProcedure
IntersectIfDefined
  ├── uses → UnsetMarker
  └── uses → Simplify
DefaultValue
  └── uses → UnsetMarker
inferSubscriptionOutput
  └── uses → TypeError
AnyProcedureBuilderDef
  └── uses → ProcedureBuilderDef
ProcedureResolver
  ├── uses → MaybePromise
  └── uses → DefaultValue
AnyResolver
  └── uses → ProcedureResolver
inferProcedureBuilderResolverOptions
  ├── uses → UnsetMarker
  └── uses → Simplify
AnyRootTypes
  └── uses → CreateRootTypes
DecorateProcedure
  └── uses → TRPCError
DecorateRouterRecord
  ├── uses → AnyProcedure
  ├── uses → DecorateProcedure
  └── uses → RouterRecord
RouterCaller
  ├── uses → MaybePromise
  └── uses → RouterCallerErrorHandler
CreateRouterOptions
  ├── uses → AnyProcedure
  ├── uses → AnyRouter
  └── uses → Lazy
DecorateCreateRouterOptions
  ├── uses → AnyProcedure
  ├── uses → Lazy
  └── uses → CreateRouterOptions
MergeRouters
  ├── uses → Head
  ├── uses → AnyRouter
  └── uses → BuiltRouter
InputDataTransformer
  └── extends → DataTransformer
OutputDataTransformer
  └── extends → DataTransformer
CombinedDataTransformerClient
  └── uses → CombinedDataTransformer
DataTransformerOptions
  ├── uses → CombinedDataTransformer
  └── uses → DataTransformer
Filter
  └── uses → FilterKeys
Overwrite
  └── uses → WithoutIndexSignature
ProtectedIntersection
  └── uses → IntersectionError
ProcedureErrorFormatter
  ├── uses → Simplify
  └── uses → Overwrite
AnyProcedureErrorFormatter
  └── uses → ProcedureErrorFormatter
DefaultErrorData
  └── uses → TRPC_ERROR_CODE_KEY
UtilityParser
  └── uses → ParserZodEsque
OctetInput
  └── uses → FileLike
ResultTuple
  └── uses → TRPCError
RPCResult
  ├── uses → ResultTuple
  └── uses → RPCResultOk
HTTPHeaders
  └── uses → Dict
ResponseMetaFn
  └── uses → TRPCResponse
ResolveHTTPRequestOptionsContextFn
  └── uses → TRPCRequestInfo
TRPC_ERROR_CODE_NUMBER
  └── uses → ValueOf
TRPCRequestMessage
  └── uses → RequestId
TRPCClientOutgoingMessage
  ├── uses → TRPCRequestMessage
  └── uses → RequestId
TRPCResponseMessage
  └── uses → RequestId
TRPCClientIncomingMessage
  ├── uses → TRPCClientIncomingRequest
  └── uses → TRPCResponseMessage
ChunkValueType
  ├── uses → CHUNK_VALUE_TYPE_PROMISE
  └── uses → CHUNK_VALUE_TYPE_ASYNC_ITERABLE
ChunkDefinition
  ├── uses → ChunkDefinitionKey
  ├── uses → ChunkValueType
  └── uses → ChunkIndex
EncodedValue
  └── uses → ChunkDefinition
Head
  └── uses → EncodedValue
PromiseChunk
  ├── uses → ChunkIndex
  ├── uses → PROMISE_STATUS_FULFILLED
  ├── uses → EncodedValue
  └── uses → PROMISE_STATUS_REJECTED
IterableChunk
  ├── uses → ChunkIndex
  ├── uses → ASYNC_ITERABLE_STATUS_RETURN
  ├── uses → EncodedValue
  ├── uses → ASYNC_ITERABLE_STATUS_YIELD
  └── uses → ASYNC_ITERABLE_STATUS_ERROR
ChunkData
  ├── uses → PromiseChunk
  └── uses → IterableChunk
MessageEvent
  └── extends → Event
EventSourceListenerLike
  └── uses → Event
AnyConstructorLike
  └── uses → Instance
AnyConstructor
  └── uses → AnyConstructorLike
EventOf
  └── uses → ListenerOf
TrackedEnvelope
  └── uses → TrackedId
inferTrackedOutput
  └── uses → TrackedEnvelope

---

Generated by RepoLens static analysis. Type detection uses regex-based parsing and may not capture all advanced TypeScript patterns.

<!-- repolens:docs-badge -->  · Examples

73 files · 146 imports · 3 external packages · ✓ no circular dependencies · 5 orphan file(s)

This document maps every import relationship in the codebase, identifies the most-connected modules, and flags circular dependencies that may complicate refactoring or increase build times.

Overview

Hub Modules

These are the most-imported modules in the codebase. Changes to hub modules have the widest blast radius and should be reviewed carefully:

External Dependencies

The codebase imports 3 external packages. These are third-party modules (not the language standard library):

---

Generated by RepoLens import analysis. Dependency detection covers JavaScript and TypeScript (ES modules, dynamic import, CommonJS, re-exports; comments, strings, and type-only imports are skipped), Python (`import` / `from ... import`, including relative imports), and Go (`go.mod` module paths). Go `_test.go` files are not part of the graph.*

<!-- repolens:docs-badge -->  · Examples

No baseline found. Run repolens publish once to establish a baseline.

A baseline snapshot of the current architecture has been saved. On subsequent runs, this report will track structural changes across the following dimensions:

<!-- repolens:docs-badge -->  · Examples

5 security finding(s) · 5 low severity · across 4 file(s)

This report identifies code patterns that are commonly associated with security vulnerabilities. Each finding includes the relevant CWE classification and a recommended remediation.

Severity Overview

73 source files scanned · 4 files with findings

Prototype Pollution

Deep merge utilities may be vulnerable to prototype pollution if they don't check hasOwnProperty. Verify the implementation.

Affected Files

• packages/server/src/unstable-core-do-not-import/router.ts
• packages/server/src/unstable-core-do-not-import/utils.ts
• packages/server/src/unstable-core-do-not-import/error/TRPCError.ts
• packages/server/src/unstable-core-do-not-import/stream/jsonl.ts

---

Generated by RepoLens security pattern analysis. Detection is regex-based and may produce false positives. Findings should be triaged by a security-aware engineer.

<!-- repolens:docs-badge -->  · Examples

73 files analyzed · Average health: 89/100 · 58 A, 7 B, 7 C, 1 D, 0 F

This report synthesizes complexity, coupling, documentation, and security signals into a single health score per module. Lower scores indicate higher risk and maintenance burden.

Overview

Grade Distribution

Hotspots — Priority Refactoring Targets

These modules have the lowest health scores and should be prioritized for improvement:

Most Complex Functions

These functions have the highest cyclomatic complexity and are the most likely sources of bugs:

All Modules by Health Score

Showing 50 of 73 modules (sorted worst-first)

Scoring Methodology

The health score (0–100) is computed from four dimensions:

---

Generated by RepoLens code health analysis. Complexity covers JavaScript/TypeScript, Python, and Go. It is regex-based and may differ from AST-based tools. Scores are relative indicators, not absolute quality measures.

<!-- repolens:docs-badge -->  · Examples