Hono architecture: modules, API surface, dependency graph

At a Glance

---

What This System Does

Hono is a general-purpose API service built with TypeScript, Node.js. It exposes 53 API endpoints, designed for programmatic access by client applications, mobile apps, or external services.

Business Capabilities

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

Technical Foundation

Module Composition

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

Codebase Health

Overall Health: 🟡 60/100

Key Insights

• 🔴 Architectural concern — 5 circular dependencies detected. These create tight coupling and make testing difficult.
• ⚠️ Potential dead code — 19 files (10%) are not imported anywhere.

Key Data Flows

The system processes information through 7 identified flows:

• dom Request Flow (critical) — Import chain starting from src/jsx/dom — traces how this entry point depends on 1 downstream module
• bun Request Flow (critical) — Import chain starting from src/adapter/bun — traces how this entry point depends on 1 downstream module
• css Request Flow (critical) — Import chain starting from src/helper/css — traces how this entry point depends on 1 downstream module
• deno Request Flow — Import chain starting from src/adapter/deno — traces how this entry point depends on 3 downstream modules
• jsx-runtime Request Flow — Import chain starting from src/jsx/jsx-runtime — traces how this entry point depends on 2 downstream modules

Strategic Observations

• The codebase follows Middleware pipeline — `src/middleware`, Shared utility layer — `src/utils`, `src/helper`; high fan-in, Integration adapters — `src/adapter`, ⚠️ 5 circular dependency cycle(s) detected architectural patterns, providing a familiar structure for developers.
• With 7 distinct domains, the system has clear separation of concerns suitable for team-based development.

---

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

Hono is a focused codebase with a clear purpose, containing 19 modules spread across 188 files.

---

Technology Stack

The system is built on a modern technology foundation:

Architecture Patterns

The codebase follows 4 identified architectural patterns:

• Middleware pipeline — `src/middleware` — A structured approach to organizing code and managing complexity.
• Shared utility layer — `src/utils`, `src/helper`; high fan-in — A structured approach to organizing code and managing complexity.
• Integration adapters — `src/adapter` — A structured approach to organizing code and managing complexity.
• ⚠️ 5 circular dependency cycle(s) detected — A structured approach to organizing code and managing complexity.

Module Architecture

The system is organized into 5 architectural layers:

Layer Details

integration — 1 module

• src/adapter — 37 files — Core application module

middleware — 1 module

• src/middleware — 36 files — Request/response middleware

Other Modules — 10 modules

• src/jsx — 27 files — Core application module
• src/client — 5 files — Core application module
• src/validator — 3 files — Core application module
• src/preset — 2 files — Core application module
• +6 more modules

Shared Libraries — 2 modules

• src/utils — 27 files — Utility and helper functions
• src/helper — 25 files — Utility and helper functions

Route/Page Modules — 1 module

• src/router — 16 files — API layer and route handlers

Functional Domains

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

Route Summary

The system surfaces 50 API endpoints (GET, POST, ALL, DELETE).

API Endpoints (50)

Dependency Graph

Codebase Health: 🟡 60/100

---

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

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

Quick Reference:

---

1. Other

Business Capability

Uncategorized module

This is a major domain with 12 modules and 56 source files.

Key Modules

User-Facing Interfaces

API Endpoints:

• 🔌 /itty-router/* [ALL] — Data operations

Business Impact

• Change Frequency Impact: High — Changes here affect 56 files
• Domain Complexity: Complex (multiple modules)
• Recommendation: Ensure comprehensive testing before modifying this domain

---

2. Shared Utilities

Business Capability

path src/utils matches util

This is a major domain with 2 modules and 52 source files.

Key Modules

Business Impact

• Change Frequency Impact: High — Changes here affect 52 files
• Domain Complexity: Simple
• Recommendation: Ensure comprehensive testing before modifying this domain

---

3. Integrations

Business Capability

path src/adapter matches adapter

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

Key Modules

Business Impact

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

---

4. API Layer

Business Capability

path src/middleware matches middleware

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

Key Modules

Business Impact

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

---

5. Services

Business Capability

path src/client matches client

This is a focused domain with 1 module and 5 source files.

Key Modules

Business Impact

• Change Frequency Impact: Low — Changes here affect 5 files
• Domain Complexity: Simple

---

6. State Management

Business Capability

path src/context.ts matches context

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

---

7. Search & Discovery

Business Capability

path 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

---

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

Hono follows a Middleware pipeline — `src/middleware` architecture with elements of Shared utility layer — `src/utils`, `src/helper`; high fan-in, Integration adapters — `src/adapter`, ⚠️ 5 circular dependency cycle(s) detected.

Pattern Analysis

Middleware pipeline — `src/middleware`

A structured approach to organizing code and managing complexity.

Benefits: Structured organization, maintainability, clarity

Shared utility layer — `src/utils`, `src/helper`; high fan-in

A structured approach to organizing code and managing complexity.

Benefits: Structured organization, maintainability, clarity

Integration adapters — `src/adapter`

A structured approach to organizing code and managing complexity.

Benefits: Structured organization, maintainability, clarity

⚠️ 5 circular dependency cycle(s) detected

A structured approach to organizing code and managing complexity.

Benefits: Structured organization, maintainability, clarity

System Layers

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

Module Layers

Modules are classified into 5 architectural roles:

integration

Role: Supporting application functionality

middleware

Role: Supporting application functionality

Other Modules

Role: General purpose functionality

Shared Libraries

Role: Provides shared utilities and abstractions used across modules

Route/Page Modules

Role: Maps URL paths to page components and handles navigation

Technology Foundation

Scale & Complexity Analysis

Dependency Health

Architecture Health Score: 🟡 60/100

Architectural Strengths

• Testing infrastructure — Automated testing with Vitest supports confident evolution.

Concerns

• Circular dependencies detected — 5 circular dependencies create tight coupling, complicate testing, and hinder refactoring. Priority: High.

---

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: 19

---

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.

---

API Endpoints (53)

Backend services that handle data operations and business logic.

---

Paths starting with `/api/` are backend endpoints; all others are user-facing pages.

<!-- 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.

Total endpoints: 53

---

External API Integrations

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

Package Management

---

Documented Exports

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

⚠️ Deprecated Functions

• isContentEncodingBinary in src/adapter/aws-lambda/handler.ts: hono/aws-lambda will be removed in v5. Install @hono/aws-lambda and import from there instead.
• handle in src/adapter/vercel/handler.ts: hono/vercel will be removed in v5. Install @hono/vercel and import from there instead.
• SSG_DISABLED_RESPONSE in src/helper/ssg/middleware.ts: Use X_HONO_DISABLE_SSG_HEADER_KEY instead. This constant will be removed in the next minor version.

Function Documentation

src/adapter/aws-lambda/handler.ts

`isContentEncodingBinary()` ⚠️

src/adapter/vercel/handler.ts

`handle()` ⚠️

src/client/fetch-result-please.ts

`fetchRP()`

Smartly parses and return the consumable result from a fetch Response. Throwing a structured error if the response is not ok. ({@link DetailedError})

src/helper/ssg/middleware.ts

`SSG_DISABLED_RESPONSE()` ⚠️

src/jsx/streaming.ts

`renderToReadableStream()`

src/middleware/cache/index.ts

`cache()`

Cache Middleware for Hono.

Parameters:

• options (Object): The options for the cache middleware.
• options.cacheName (string | Function): The name of the cache. Can be used to store multiple caches with different identifiers.
• options.wait (boolean) (optional): =false] - A boolean indicating if Hono should wait for the Promise of the cache.put function to resolve before continuing with the request. Required to be true for the Deno environment.
• options.cacheControl (string) (optional): A string of directives for the Cache-Control header.
• options.vary (string | string[]) (optional): Adds the configured request headers to the cache key variants and sets the Vary header in the response. If the original response header already contains a Vary header, the values are merged, removing any duplicates.
• options.keyGenerator (Function) (optional): Generates keys for every request in the cacheName store. This can be used to cache data based on request parameters or context parameters. QUERY keys additionally include a digest of the request content and its representation metadata.
• options.maxQueryBodySize (number) (optional): =65536] - The maximum QUERY request body size in bytes that can be cached. Larger QUERY requests bypass the cache.
• options.cacheableStatusCodes (number[]) (optional): =[200]] - An array of status codes that can be cached.
• options.onCacheNotAvailable (Function | false) (optional): A callback invoked with the reason when globalThis.caches is not available or QUERY caching cannot use Web Crypto. By default, the reason is logged to the console. Set to false to suppress the log, or provide a custom function.

Returns: MiddlewareHandler — The middleware handler function.

Throws:

• {Error} If the vary option includes "*".

src/middleware/ip-restriction/index.ts

`ipRestriction()`

IP Restriction Middleware for Hono.

Parameters:

• getIP (GetConnInfo | ((c: Context) => string)): A function to retrieve the client IP address. Use getConnInfo from the appropriate runtime adapter.
• rules (IPRestrictionRules): An object with optional denyList and allowList arrays of IP rules. Each rule can be a static IP, a CIDR range, or a custom function.

Returns: MiddlewareHandler — The middleware handler function.

src/middleware/jwk/jwk.ts

`jwk()`

JWK Auth Middleware for Hono.

Parameters:

• options (object): The options for the JWK middleware.
• options.keys (HonoJsonWebKey[] | ((ctx: Context) => Promise<HonoJsonWebKey[]> | HonoJsonWebKey[])) (optional): The public keys used for JWK verification, or a function that returns them.
• options.jwks_uri (string | ((ctx: Context) => Promise<string> | string)) (optional): If set to a URI string or a function that returns a URI string, attempt to fetch JWKs from it. The response must be a JSON object containing a keys array, which will be merged with the keys option.
• options.allow_anon (boolean) (optional): If set to true, the middleware allows requests without a token to proceed without authentication.
• options.cookie (string) (optional): If set, the middleware attempts to retrieve the token from a cookie with these options (optionally signed) only if no token is found in the header.
• options.headerName (string) (optional): ='Authorization'] - The name of the header to look for the JWT token. Default is 'Authorization'.
• options.realm (string) (optional): The protection space described by the realm parameter of the returned WWW-Authenticate challenge header. Defaults to the request URL.
• options.alg (AsymmetricAlgorithm[]): An array of allowed asymmetric algorithms for JWT verification. Only tokens signed with these algorithms will be accepted.
• init (RequestInit) (optional): Optional init options for the fetch request when retrieving JWKS from a URI.
• options.verification (VerifyOptions) (optional): Additional options for JWK payload verification.

Returns: MiddlewareHandler — The middleware handler function.

src/middleware/language/language.ts

`parseAcceptLanguage()`

Parse Accept-Language header values with quality scores

Parameters:

• header (any): Accept-Language header string

Returns: void — Array of parsed languages with quality scores

`detectFromHeader()`

Detects language from Accept-Language header

`detectFromPath()`

Detects language from URL path

`validateOptions()`

Validate detector options

Parameters:

• options (any): Detector options to validate

Throws:

• Error if options are invalid

src/middleware/request-id/request-id.ts

`requestId()`

Request ID Middleware for Hono.

Parameters:

• options (object): Options for Request ID middleware.
• options.limitLength (number) (optional): =255] - The maximum length of request id.
• options.headerName (string) (optional): =X-Request-Id] - The header name used in request id.
• options.generator (generator) (optional): =() => crypto.randomUUID()] - The request id generation function.

Returns: MiddlewareHandler — The middleware handler function.

src/middleware/timing/timing.ts

`startTime()`

Start a timer for the timing middleware.

Parameters:

• c (Context): The context of the request.
• name (string): The name of the timer.
• description (string) (optional): The description of the timer.

`endTime()`

End a timer for the timing middleware.

Parameters:

• c (Context): The context of the request.
• name (string): The name of the timer.
• precision (number) (optional): The precision of the timer value.

src/utils/color.ts

`getColorEnabled()`

Get whether color change on terminal is enabled or disabled. If NO_COLOR environment variable is set, this function returns false. Unlike getColorEnabledAsync(), this cannot check Cloudflare environment variables.

Returns: boolean

`getColorEnabledAsync()`

Get whether color change on terminal is enabled or disabled. If NO_COLOR environment variable is set, this function returns false.

Returns: boolean

---

Documentation Summary:

• Total exports: 45
• Documented: 17
• Undocumented: 28
• Coverage: 38%

---

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 Hono — from external inputs through processing layers to storage or presentation. Understanding these flows is essential for debugging, performance optimization, and architectural decisions.

Flow Summary

7 data flows identified in the codebase:

---

1. dom Request Flow 🔴 CRITICAL FLOW

Description

Import chain starting from src/jsx/dom — traces how this entry point depends on 1 downstream module

Characteristics

Processing Steps

Flow Diagram

┌─ START ─┐
│ `dom` (entry point, imports 10 modules)            │
│         ↓
│ `constants` (shared infrastructure, used by 13 ... │
└─ END ───┘

Involved Modules

Dependencies

Shared libraries used: src/utils

Insights

• ⚠️ Critical path — Failures here have significant business impact
• 📊 Consider adding monitoring and alerting
• 🧪 Ensure comprehensive test coverage

---

2. bun Request Flow 🔴 CRITICAL FLOW

Description

Import chain starting from src/adapter/bun — traces how this entry point depends on 1 downstream module

Characteristics

Processing Steps

Flow Diagram

┌─ START ─┐
│ `bun` (entry point, imports 5 modules)             │
│         ↓
│ `server` (leaf — no further dependencies)          │
└─ END ───┘

Involved Modules

Dependencies

Shared libraries used: src/utils

Insights

• ⚠️ Critical path — Failures here have significant business impact
• 📊 Consider adding monitoring and alerting
• 🧪 Ensure comprehensive test coverage

---

3. css Request Flow 🔴 CRITICAL FLOW

Description

Import chain starting from src/helper/css — traces how this entry point depends on 1 downstream module

Characteristics

Processing Steps

Flow Diagram

┌─ START ─┐
│ `css` (entry point, imports 5 modules)             │
│         ↓
│ `constants` (shared infrastructure, used by 13 ... │
└─ END ───┘

Involved Modules

Dependencies

Shared libraries used: src/utils

Insights

• ⚠️ Critical path — Failures here have significant business impact
• 📊 Consider adding monitoring and alerting
• 🧪 Ensure comprehensive test coverage

---

4. deno Request Flow

Description

Import chain starting from src/adapter/deno — traces how this entry point depends on 3 downstream modules

Characteristics

Processing Steps

Flow Diagram

┌─ START ─┐
│ `deno` (entry point, imports 4 modules)            │
│         ↓
│ `serve-static` → imports 1 module                  │
│         ↓
│ `serve-static` → imports 5 modules                 │
│         ↓
│ `url` (shared infrastructure, used by 9 files)     │
└─ END ───┘

Involved Modules

Dependencies

Shared libraries used: src/utils

Insights

• Standard integration flow with 4 processing steps

---

5. jsx-runtime Request Flow

Description

Import chain starting from src/jsx/jsx-runtime — traces how this entry point depends on 2 downstream modules

Characteristics

Processing Steps

Flow Diagram

┌─ START ─┐
│ `jsx-runtime` (entry point, imports 4 modules)     │
│         ↓
│ `html` (shared infrastructure, used by 9 files)    │
│         ↓
│ `html` (shared infrastructure, used by 8 files)    │
└─ END ───┘

Involved Modules

Dependencies

Shared libraries used: src/utils

Insights

• Standard integration flow with 3 processing steps

---

6. Authentication Flow 🔴 CRITICAL FLOW

Description

User authentication and session management

Characteristics

Processing Steps

Flow Diagram

┌─ START ─┐
│ User submits login credentials                     │
│         ↓
│ Auth API validates credentials                     │
│         ↓
│ Session is created and stored                      │
│         ↓
│ User is redirected to authenticated area           │
│         ↓
│ Subsequent requests include auth token             │
└─ END ───┘

Dependencies

Shared libraries used: src/utils

External services: Authentication service

Insights

• ⚠️ Critical path — Failures here have significant business impact
• 📊 Consider adding monitoring and alerting
• 🧪 Ensure comprehensive test coverage

---

7. API Integration Flow

Description

External service integrations and backend processing

Characteristics

Processing Steps

Flow Diagram

┌─ START ─┐
│ Frontend makes API request                         │
│         ↓
│ API route receives and validates request           │
│         ↓
│ Business logic is executed                         │
│         ↓
│ External services may be called                    │
│         ↓
│ Response is formatted and returned                 │
└─ END ───┘

Involved Modules

Dependencies

Shared libraries used: src/utils

Insights

• Standard integration flow with 5 processing steps

---

Import Network

The system has 288 internal import edges connecting 188 source files.

Network Topology

---

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: 19 modules and 43 relationships

Source: Real import analysis

---

Architecture Diagram

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

🎯  CLI ENTRY
│
└── client (5 files)
       → utils
│
🔌  INTEGRATION
│
└── adapter (37 files)
       → utils
       → middleware
       → helper
       ... +2 more
│
📄  PAGES / ROUTES
│
├── router (16 files)
└── router.ts (1 file)
       → router
       → utils
│
🔀  MIDDLEWARE
│
└── middleware (36 files)
       → http-exception.ts
       → utils
       → request.ts
       ... +6 more
│
🛠️  UTILITIES
│
├── utils (27 files)
│      → helper
└── helper (25 files)
       → utils
       → jsx
       → hono.ts
       ... +5 more
│
📦  OTHER
│
├── jsx (27 files)
│      → helper
│      → utils
├── validator (3 files)
│      → helper
│      → http-exception.ts
│      → utils
├── preset (2 files)
│      → hono-base.ts
│      → router.ts
├── compose.ts (1 file)
├── context.ts (1 file)
│      → request.ts
│      → utils
├── hono-base.ts (1 file)
│      → compose.ts
│      → context.ts
│      → router
│      ... +1 more
├── hono.ts (1 file)
│      → hono-base.ts
│      → router.ts
├── http-exception.ts (1 file)
├── index.ts (1 file)
├── request.ts (1 file)
│      → http-exception.ts
│      → utils
├── types.ts (1 file)
└── request (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 Hono! 👋

This guide will help you get up to speed quickly. Hono is a general-purpose tools project built with TypeScript, Node.js, containing 19 modules across 188 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. `src` — Application source code

---

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 Routes

Understanding the routing structure helps you trace user interactions through the system.

API Endpoints

---

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 hono
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:

• Circular dependencies — This codebase has 5 circular imports. Be careful not to introduce more.
• 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

80 file(s) with type declarations · 165 interface(s) · 59 type alias(es) · 28 class(es) · 3 enum(s) · 216 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

165 interfaces define the data contracts used across the application:

Classes

28 classes provide concrete implementations:

Type Aliases

59 type aliases define computed or composite types:

Enums

3 enums define named constant sets:

Type Relationships

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

LambdaEvent
  ├── uses → APIGatewayProxyEvent
  ├── uses → APIGatewayProxyEventV2
  ├── uses → ALBProxyEvent
  ├── uses → LatticeProxyEventV2
  ├── uses → LatticeRequestContextV2
  ├── uses → ApiGatewayRequestContextV2
  ├── uses → ApiGatewayRequestContext
  ├── uses → ALBRequestContext
  ├── uses → LambdaContext
  ├── uses → Response
  └── uses → Cookie
PagesFunction
  ├── uses → Params
  └── uses → Response
CloudFrontOrigin
  └── uses → CloudFrontS3Origin
CloudFrontContext
  ├── uses → Callback
  ├── uses → CloudFrontRequest
  ├── uses → CloudFrontResult
  ├── uses → CloudFrontHeaders
  ├── uses → CloudFrontEdgeEvent
  ├── uses → Response
  └── uses → CloudFrontEvent
FetchEvent
  └── extends → ExtendableEvent
MethodNameAll
  └── uses → ClientResponseOfEndpoint
ClientResponseOfEndpoint
  └── uses → Response
HeaderRecord
  ├── uses → BaseMime
  ├── uses → ExecutionContext
  ├── uses → ContextVariableMap
  ├── uses → ContextRenderer
  ├── uses → DefaultRenderer
  ├── uses → Response
  ├── uses → Props
  ├── uses → NewResponse
  ├── uses → BodyRespond
  ├── uses → TextRespond
  ├── uses → JSONRespond
  ├── uses → HTMLRespond
  ├── uses → FetchEventLike
  ├── uses → RouterRoute
  ├── uses → SetHeadersOptions
  └── uses → SetHeaders
GetPath
  ├── uses → RouterRoute
  ├── uses → Context
  └── uses → ErrorHandler
Body
  ├── uses → RouterRoute
  └── uses → Response
acceptsOptions
  └── extends → acceptsConfig
Runtime
  ├── uses → Context
  └── uses → Node
CssVariableBasicType
  ├── uses → CssClassName
  └── uses → CssEscapedString
ClassNameSlug
  └── uses → CssClassName
CssClassName
  ├── uses → CssType
  ├── uses → CxType
  ├── uses → KeyframesType
  ├── uses → ViewTransitionType
  └── uses → StyleType
SSGParams
  ├── uses → SSGParam
  ├── uses → SSGParamsMiddleware
  ├── uses → Context
  └── uses → Route
BeforeRequestHook
  ├── uses → Response
  ├── uses → ToSSGResult
  ├── uses → FileSystemModule
  ├── uses → ToSSGOptions
  └── uses → SSGPlugin
SSEStreamingApi
  └── extends → StreamingApi
Props
  ├── uses → JSXNode
  ├── uses → Child
  ├── uses → HTMLAttributes
  ├── uses → ElementChildrenAttribute
  ├── uses → IntrinsicElements
  ├── uses → IntrinsicAttributes
  └── uses → Context
Child
  ├── uses → JSXNode
  └── uses → Props
JSXFunctionNode
  └── extends → JSXNode
JSXFragmentNode
  └── extends → JSXNode
ErrorHandler
  └── uses → Child
RenderStore
  ├── uses → Context
  └── uses → Node
HTMLAttributes
  ├── extends → JSXAttributes
  └── extends → EventAttributes
AnchorHTMLAttributes
  └── extends → HTMLAttributes
AudioHTMLAttributes
  └── extends → MediaHTMLAttributes
AreaHTMLAttributes
  └── extends → HTMLAttributes
BaseHTMLAttributes
  └── extends → HTMLAttributes
BlockquoteHTMLAttributes
  └── extends → HTMLAttributes
ButtonHTMLAttributes
  └── extends → HTMLAttributes
CanvasHTMLAttributes
  └── extends → HTMLAttributes
ColHTMLAttributes
  └── extends → HTMLAttributes
ColgroupHTMLAttributes
  └── extends → HTMLAttributes
DataHTMLAttributes
  └── extends → HTMLAttributes
DetailsHTMLAttributes
  └── extends → HTMLAttributes
DelHTMLAttributes
  └── extends → HTMLAttributes
DialogHTMLAttributes
  └── extends → HTMLAttributes
EmbedHTMLAttributes
  └── extends → HTMLAttributes
FieldsetHTMLAttributes
  └── extends → HTMLAttributes
FormHTMLAttributes
  └── extends → HTMLAttributes
HtmlHTMLAttributes
  └── extends → HTMLAttributes
IframeHTMLAttributes
  └── extends → HTMLAttributes
ImgHTMLAttributes
  └── extends → HTMLAttributes
InsHTMLAttributes
  └── extends → HTMLAttributes
InputHTMLAttributes
  └── extends → HTMLAttributes
KeygenHTMLAttributes
  └── extends → HTMLAttributes
LabelHTMLAttributes
  └── extends → HTMLAttributes
LiHTMLAttributes
  └── extends → HTMLAttributes
LinkHTMLAttributes
  └── extends → HTMLAttributes
MapHTMLAttributes
  └── extends → HTMLAttributes
MenuHTMLAttributes
  └── extends → HTMLAttributes
MediaHTMLAttributes
  └── extends → HTMLAttributes
MetaHTMLAttributes
  └── extends → HTMLAttributes
MeterHTMLAttributes
  └── extends → HTMLAttributes
QuoteHTMLAttributes
  └── extends → HTMLAttributes
ObjectHTMLAttributes
  └── extends → HTMLAttributes
OlHTMLAttributes
  └── extends → HTMLAttributes
OptgroupHTMLAttributes
  └── extends → HTMLAttributes
OptionHTMLAttributes
  └── extends → HTMLAttributes
OutputHTMLAttributes
  └── extends → HTMLAttributes
ParamHTMLAttributes
  └── extends → HTMLAttributes
ProgressHTMLAttributes
  └── extends → HTMLAttributes
SlotHTMLAttributes
  └── extends → HTMLAttributes
ScriptHTMLAttributes
  └── extends → HTMLAttributes
SelectHTMLAttributes
  └── extends → HTMLAttributes
SourceHTMLAttributes
  └── extends → HTMLAttributes
StyleHTMLAttributes
  └── extends → HTMLAttributes
TableHTMLAttributes
  └── extends → HTMLAttributes
TextareaHTMLAttributes
  └── extends → HTMLAttributes
TdHTMLAttributes
  └── extends → HTMLAttributes
ThHTMLAttributes
  └── extends → HTMLAttributes
TimeHTMLAttributes
  └── extends → HTMLAttributes
TrackHTMLAttributes
  └── extends → HTMLAttributes
VideoHTMLAttributes
  └── extends → MediaHTMLAttributes
HasRenderToDom
  ├── uses → ErrorHandler
  ├── uses → Child
  ├── uses → Props
  ├── uses → Node
  ├── uses → Context
  └── uses → JSXNode
UpdateMapResolve
  └── uses → Context
FormStatus
  └── uses → Context
MessageFunction
  ├── uses → Context
  ├── uses → Auth
  ├── uses → Callback
  └── uses → HTTPException
OnError
  ├── uses → Context
  ├── uses → Response
  ├── uses → Body
  ├── uses → HTTPException
  └── uses → Encoding
CacheKeyRequest
  ├── uses → Response
  ├── uses → Cookie
  └── uses → Context
Condition
  └── uses → Context
Encoding
  └── uses → CompressionOptions
GetIPAddr
  └── uses → Context
RendererOptions
  ├── uses → Context
  ├── uses → JSXNode
  └── uses → Encoding
ContextVariableMap
  ├── extends → JwtVariables
  ├── extends → LanguageVariables
  ├── extends → SecureHeadersVariables
  └── extends → TimingVariables
JwtVariables
  ├── uses → Auth
  └── uses → VerifyOptions
DetectorType
  ├── uses → DetectorOptions
  ├── uses → Cookie
  ├── uses → LanguageVariables
  └── uses → Accept
SecureHeadersVariables
  ├── uses → Context
  ├── uses → ContentSecurityPolicyOptions
  ├── uses → ReportToOptions
  ├── uses → ReportToEndpoint
  ├── uses → ReportingEndpointOptions
  └── uses → SecureHeadersOptions
SecureHeadersCallback
  ├── uses → Context
  ├── uses → SecureHeadersOptions
  ├── uses → ContentSecurityPolicyOptions
  ├── uses → ReportingEndpointOptions
  └── uses → ReportToOptions
TimingVariables
  ├── uses → Timer
  ├── uses → TimingOptions
  ├── uses → Context
  └── uses → Response
Route
  ├── uses → UnsupportedPathError
  └── uses → Params
ParamAssocArray
  ├── uses → Context
  └── uses → Node
ReplacementMap
  ├── uses → Trie
  ├── uses → Context
  └── uses → Node
HandlerSet
  ├── uses → Node
  └── uses → Pattern
BodyDataValueDot
  └── uses → ParseBody
StringHashFunction
  └── uses → Response
CookieOptions
  └── uses → SecureCookieConstraint
VerifyOptions
  ├── uses → JwtAlgorithmRequired
  ├── uses → JwtTokenInvalid
  ├── uses → JwtHeaderInvalid
  ├── uses → JwtAlgorithmMismatch
  ├── uses → JwtTokenNotBefore
  ├── uses → JwtTokenExpired
  ├── uses → JwtTokenIssuedAt
  ├── uses → JwtTokenIssuer
  ├── uses → JwtPayloadRequiresAud
  ├── uses → JwtTokenAudience
  ├── uses → JwtTokenSignatureMismatched
  ├── uses → AlgorithmTypes
  ├── uses → HonoJsonWebKey
  ├── uses → JwtHeaderRequiresKid
  ├── uses → JwtSymmetricAlgorithmNotAllowed
  ├── uses → JwtAlgorithmNotAllowed
  └── uses → TokenHeader
ValidationTargetKeysWithBody
  └── uses → Context
ExtractValidationResponse
  ├── uses → Response
  ├── uses → Context
  └── uses → HTTPException

---

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

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

188 files · 288 imports · 0 external packages · ⚠️ 5 circular dependency cycle(s) · 19 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

Circular Dependencies

5 circular dependency chains were detected. Circular imports can cause initialization errors, increase bundle sizes, and make modules harder to test in isolation. Consider refactoring shared logic into a separate module.

1. src/jsx/base → src/jsx/context → src/jsx/base
2. src/jsx/context → src/jsx/dom/context → src/jsx/context
3. src/jsx/base → src/jsx/intrinsic-element/components → src/jsx/base
4. src/jsx/hooks → src/jsx/dom/render → src/jsx/hooks
5. src/jsx/components → src/jsx/streaming → src/jsx/components

---

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

24 security finding(s) · 3 high severity · 4 medium severity · 17 low severity · across 17 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

188 source files scanned · 17 files with findings

Prototype Pollution

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

ReDoS

Dynamic regex construction from user input can cause ReDoS. Use static regex or input validation.

Cross-Site Scripting (XSS)

dangerouslySetInnerHTML bypasses React's XSS protection. Ensure content is sanitized before use.

SQL Injection

Concatenating user input into SQL queries enables injection attacks. Use parameterized queries or prepared statements.

Affected Files

• src/client/utils.ts
• src/hono-base.ts
• src/helper/css/common.ts
• src/helper/css/index.ts
• src/jsx/base.ts
• src/jsx/intrinsic-elements.ts
• src/jsx/streaming.ts
• src/jsx/dom/render.ts
• src/jsx/dom/intrinsic-element/components.ts
• src/jsx/hooks/index.ts
• src/middleware/bearer-auth/index.ts
• src/router/linear-router/router.ts
• src/router/pattern-router/router.ts
• src/router/reg-exp-router/router.ts
• src/router/reg-exp-router/trie.ts
• src/utils/ipaddr.ts
• src/utils/url.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

188 files analyzed · Average health: 84/100 · 129 A, 23 B, 31 C, 3 D, 2 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 188 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