Gallery ยท Architecture explained ยท Score ยท JavaScript
Express architecture: modules, API surface, dependency graph
Fast, unopinionated, minimalist web framework for Node.js. Generated from expressjs/express at 0dee2c5, MIT.
- Files
- 7
- Modules
- 7
- API routes
- 9
- Documents
- 17
Node.jsJavaScript
Executive Summary
At a Glance
| Aspect | Summary |
|---|---|
| What | Express is a well-structured API service |
| Built With | general-purpose + Node.js, JavaScript |
| Scale | 7 modules across 7 files |
| Maturity | Well-structured (2/3 indicators) |
What This System Does
Express is a general-purpose API service built with Node.js, JavaScript. It exposes 9 API endpoints, designed for programmatic access by client applications, mobile apps, or external services.
Business Capabilities
The system is organized around 2 functional domains, each representing a distinct business capability:
| Domain | Capability | Scale |
|---|---|---|
| Shared Utilities | path lib/application.js matches lib | 6 modules, 6 files |
| Other | Uncategorized module | 1 modules, 1 files |
Technical Foundation
| Layer | Technologies | Purpose |
|---|---|---|
| Language | Node.js, JavaScript | Primary development language |
| Testing | Mocha | Quality assurance |
Module Composition
The codebase follows a layered architecture with clear separation of concerns:
| Layer | Count | Key Modules | Responsibility |
|---|---|---|---|
| Other Modules | 1 | root | General purpose functionality |
| Shared Libraries | 6 | application.js, express.js | Provides shared utilities and abstractions used across modules |
Codebase Health
Overall Health: ๐ข 100/100
| Metric | Value | Status |
|---|---|---|
| Internal imports | 7 edges | โ Connected |
| External Packages | 28 | โ Manageable |
| Circular Dependencies | cycle-free | โ None |
| Orphan Files | 0 | โ All connected |
Key Insights
- โ Clean module boundaries โ No circular dependencies detected, enabling safe refactoring and testing.
Key Data Flows
The system processes information through 1 identified flow:
- API Integration Flow โ External service integrations and backend processing
Strategic Observations
- The codebase follows Shared utility layer โ `lib/utils.js`, `lib/application.js`, `lib/express.js` (+3 more) architectural patterns, providing a familiar structure for developers.
- Strong engineering practices are in place: automated testing and clean dependency boundaries support ongoing 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
System Overview
The Big Picture
Express is a focused codebase with a clear purpose, containing 7 modules spread across 7 files.
| Dimension | Details |
|---|---|
| Total Files | 7 |
| Module Count | 7 |
| Functional Domains | 2 |
| API Endpoints | 9 |
Technology Stack
The system is built on a modern technology foundation:
| Layer | Technologies | Purpose |
|---|---|---|
| Language | Node.js, JavaScript | Primary development language |
| Quality | Mocha | Automated testing |
Architecture Patterns
The codebase follows 1 identified architectural pattern:
- Shared utility layer โ `lib/utils.js`, `lib/application.js`, `lib/express.js` (+3 more) โ A structured approach to organizing code and managing complexity.
Module Architecture
The system is organized into 2 architectural layers:
| Layer | Modules | Key Examples | Responsibility |
|---|---|---|---|
| Other Modules | 1 | root | General purpose functionality |
| Shared Libraries | 6 | application.js, express.js | Provides shared utilities and abstractions used across modules |
Layer Details
Other Modules โ 1 module
rootโ 1 files โ Core application module
Shared Libraries โ 6 modules
lib/application.jsโ 1 files โ Utility and helper functionslib/express.jsโ 1 files โ Utility and helper functionslib/request.jsโ 1 files โ Utility and helper functionslib/response.jsโ 1 files โ Utility and helper functions- +2 more modules
Functional Domains
The following domains represent the largest functional areas by file count:
| Rank | Domain | Scale | Business Capability |
|---|---|---|---|
| 1 | Shared Utilities | 6 files | path lib/application.js matches lib |
| 2 | Other | 1 files | Uncategorized module |
Route Summary
The system surfaces 9 API endpoints (GET).
API Endpoints (9)
| Endpoint | Methods | Purpose |
|---|---|---|
query parser fn | GET | Data operations |
trust proxy fn | GET | Data operations |
subdomain offset | GET | Data operations |
etag fn | GET | Data operations |
json escape | GET | Data operations |
json replacer | GET | Data operations |
json spaces | GET | Data operations |
jsonp callback name | GET | Data operations |
| +1 more | โ | Additional endpoints |
Dependency Graph
Codebase Health: ๐ข 100/100
| Metric | Value | Assessment |
|---|---|---|
| Internal Imports | 7 | Modules are connected |
| External Packages | 28 | Lean dependencies |
| Circular Dependencies | 0 | โ Clean |
| Orphan Files | 0 | โ All connected |
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
Business Domains
Overview
Express is organized into 2 functional domains, each representing a distinct area of business capability. This document maps the technical structure to business-oriented functional areas.
Quick Reference:
| Domain | Modules | Files | Primary Capability |
|---|---|---|---|
| Shared Utilities | 6 | 6 | Cross-cutting utility functions |
| Other | 1 | 1 | Supporting business operations |
1. Shared Utilities
Business Capability
path lib/application.js matches lib
This is a focused domain with 6 modules and 6 source files.
Key Modules
| Module | Purpose |
|---|---|
lib/application.js | Utility and helper functions |
lib/express.js | Utility and helper functions |
lib/request.js | Utility and helper functions |
lib/response.js | Utility and helper functions |
lib/utils.js | Utility and helper functions |
Business Impact
- Change Frequency Impact: Low โ Changes here affect 6 files
- Domain Complexity: Complex (multiple modules)
2. Other
Business Capability
Uncategorized module
This is a focused domain with 1 module and 1 source file.
Key Modules
| Module | Purpose |
|---|---|
root | Core application module |
Business Impact
- Change Frequency Impact: Low โ Changes here affect 1 file
- Domain Complexity: Simple
Domain Health Summary
| Metric | Value | Assessment |
|---|---|---|
| Total Domains | 2 | Consider finer-grained domain separation |
| Avg Files/Domain | 4 | Appropriate size |
| Largest Domain | Shared Utilities (6 files) | Consider breaking down |
| Domain Concentration | 86% in largest | โ ๏ธ High concentration |
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
Architecture Overview
Architectural Philosophy
Express follows a Shared utility layer โ `lib/utils.js`, `lib/application.js`, `lib/express.js` (+3 more) architecture.
Pattern Analysis
Shared utility layer โ `lib/utils.js`, `lib/application.js`, `lib/express.js` (+3 more)
A structured approach to organizing code and managing complexity.
Benefits: Structured organization, maintainability, clarity
System Layers
The system is organized into 2 functional layers, each encapsulating a distinct area of responsibility:
| Layer | Responsibility | Scale | Key Insight |
|---|---|---|---|
| Shared Utilities | path `lib/application | 6 files | Shared infrastructure โ high reuse |
| Other | Uncategorized module | 1 files | Standard domain |
Module Layers
Modules are classified into 2 architectural roles:
Other Modules
Role: General purpose functionality
| Module | Files | Description |
|---|---|---|
root | 1 | Core application module |
Shared Libraries
Role: Provides shared utilities and abstractions used across modules
| Module | Files | Description |
|---|---|---|
lib/application.js | 1 | Utility and helper functions |
lib/express.js | 1 | Utility and helper functions |
lib/request.js | 1 | Utility and helper functions |
lib/response.js | 1 | Utility and helper functions |
lib/utils.js | 1 | Utility and helper functions |
| +1 more | โ | Additional modules |
Technology Foundation
| Layer | Technologies | Architectural Implication |
|---|---|---|
| Language | Node.js, JavaScript | Dynamic typing, flexible but requires discipline |
| Quality | Mocha | Enables confident refactoring |
Scale & Complexity Analysis
| Dimension | Value | Assessment |
|---|---|---|
| Total Files | 7 | small project |
| Module Count | 7 | low complexity |
| Domain Spread | 2 domains | Focused scope |
| API Surface | 9 endpoints | Compact API |
Dependency Health
Architecture Health Score: ๐ข 100/100
| Metric | Value | Status | Recommendation |
|---|---|---|---|
| Import Edges | 7 | โ | Healthy module connectivity |
| External Packages | 28 | โ | Lean dependency set |
| Circular Deps | 0 | โ | Clean module boundaries |
| Orphan Files | 0 | โ | All code is connected |
Architectural Strengths
- Clean module boundaries โ No circular dependencies detected. This enables safe refactoring, isolated testing, and clear ownership boundaries.
- Fully connected codebase โ Every file is part of the dependency graph. No dead code or forgotten modules.
- Testing infrastructure โ Automated testing with Mocha supports confident evolution.
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
Module Catalog
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: 7
Module Inventory
| Module | Files | Role |
|---|---|---|
root | 1 | Application module |
lib/application.js | 1 | Library code and third-party integrations |
lib/express.js | 1 | Library code and third-party integrations |
lib/request.js | 1 | Library code and third-party integrations |
lib/response.js | 1 | Library code and third-party integrations |
lib/utils.js | 1 | Shared utilities and helper functions |
lib/view.js | 1 | Library code and third-party integrations |
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
Route Map
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 (9)
Backend services that handle data operations and business logic.
| Method | Path | Source File |
|---|---|---|
| GET | query parser fn | lib/request.js |
| GET | trust proxy fn | lib/request.js |
| GET | subdomain offset | lib/request.js |
| GET | etag fn | lib/response.js |
| GET | json escape | lib/response.js |
| GET | json replacer | lib/response.js |
| GET | json spaces | lib/response.js |
| GET | jsonp callback name | lib/response.js |
| GET | /user/:uid/photos/:file | lib/response.js |
Paths starting with `/api/` are backend endpoints; all others are user-facing pages.
<!-- repolens:docs-badge -->  ยท Examples
API Surface
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: 9
| Method | Path | Implementation |
|---|---|---|
| GET | query parser fn | lib/request.js |
| GET | trust proxy fn | lib/request.js |
| GET | subdomain offset | lib/request.js |
| GET | etag fn | lib/response.js |
| GET | json escape | lib/response.js |
| GET | json replacer | lib/response.js |
| GET | json spaces | lib/response.js |
| GET | jsonp callback name | lib/response.js |
| GET | /user/:uid/photos/:file | lib/response.js |
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.
HTTP method reference โ GET: retrieve data, POST: create, PUT/PATCH: update, DELETE: remove.
<!-- repolens:docs-badge -->  ยท Examples
Data Flows
Understanding Data Movement
Data flows describe how information moves through Express โ from external inputs through processing layers to storage or presentation. Understanding these flows is essential for debugging, performance optimization, and architectural decisions.
Flow Summary
1 data flow identified in the codebase:
| Flow | Type | Complexity | Critical |
|---|---|---|---|
| API Integration Flow | Integration | Medium (5 steps) | โ |
1. API Integration Flow
Description
External service integrations and backend processing
Characteristics
| Property | Value |
|---|---|
| Steps | 5 |
| Modules Involved | 1 |
| Criticality | Standard |
Processing Steps
| Step | Action | Purpose |
|---|---|---|
| 1 | Frontend makes API request | Processing step |
| 2 | API route receives and validates request | Input validation |
| 3 | Business logic is executed | Observability |
| 4 | External services may be called | Processing step |
| 5 | Response is formatted and returned | Output generation |
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
| Module | Role |
|---|---|
9 API endpoints detected | API layer and route handlers |
Dependencies
Shared libraries used: lib/application.js, lib/express.js, lib/request.js, lib/response.js, lib/utils.js
Insights
- Standard integration flow with 5 processing steps
Import Network
The system has 7 internal import edges connecting 7 source files.
Network Topology
| Metric | Value | Meaning |
|---|---|---|
| Total Edges | 7 | Direct import relationships |
| Hub Count | 0 | Central integration points |
| Avg Connections | ~1 per file | Coupling density |
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
Architecture Diff
No changes detected.
<!-- repolens:docs-badge -->  ยท Examples
System Map
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: 7 modules and 6 relationships
Source: Real import analysis
Architecture Diagram
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
โ ๐๏ธ SYSTEM ARCHITECTURE MAP โ
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
๐ ๏ธ UTILITIES
โ
โโโ application.js (1 file)
โ โ view.js
โ โ utils.js
โโโ express.js (1 file)
โ โ application.js
โ โ request.js
โ โ response.js
โโโ request.js (1 file)
โโโ response.js (1 file)
โ โ utils.js
โโโ utils.js (1 file)
โโโ view.js (1 file)
โ
๐ฆ OTHER
โ
โโโ root (1 file)
โ
Legend:
โ imports / depends on
โโ tests
Key Connections
Most depended-on modules (highest import count):
| Module | Imported by |
|---|---|
lib/utils.js | 2 modules |
lib/view.js | 1 module |
lib/application.js | 1 module |
lib/request.js | 1 module |
lib/response.js | 1 module |
Most dependent modules (highest dependency count):
| Module | Depends on |
|---|---|
lib/express.js | 3 modules |
lib/application.js | 2 modules |
lib/response.js | 1 module |
<!-- repolens:docs-badge -->  ยท Examples
Developer Onboarding
Welcome to Express! ๐
This guide will help you get up to speed quickly. Express is a general-purpose tools project built with Node.js, JavaScript, containing 7 modules across 7 files.
What You'll Learn
- โ Repository structure and organization
- โ Technology stack and tools
- โ Key modules to understand first
- โ How data flows through the system
- โ How to start contributing
Quick Reference Card
| Aspect | Details |
|---|---|
| Languages | Node.js, JavaScript |
| Frameworks | general-purpose tools |
| Build Tools | Standard toolchain |
| Testing | Mocha |
| Size | 7 modules, 7 files |
| Domains | 2 functional areas |
| API | 9 endpoints |
Repository Structure
Understanding the directory layout is your first step to navigating the codebase:
| Directory | Purpose | Start Here? |
|---|---|---|
lib | Application source code | โญ Yes |
Where to Begin
Focus on these directories first:
- `lib` โ Application source code
Technology Stack
| Layer | Technologies | What to Learn |
|---|---|---|
| Language | Node.js, JavaScript | Dynamic typing โ use console.log for runtime inspection |
| Testing | Mocha | Run existing tests to understand behavior |
Core Modules to Understand
These are the most important modules by size and centrality. Understanding them will unlock the rest of the codebase:
| Priority | Module | Files | Type | Why It Matters |
|---|---|---|---|---|
| โญ High | root | 1 | Other Modules | Key system component |
| โญ High | lib/application.js | 1 | Shared Libraries | Shared code โ reused throughout |
| โญ High | lib/express.js | 1 | Shared Libraries | Shared code โ reused throughout |
| Medium | lib/request.js | 1 | Shared Libraries | Shared code โ reused throughout |
| Medium | lib/response.js | 1 | Shared Libraries | Shared code โ reused throughout |
| Medium | lib/utils.js | 1 | Shared Libraries | Shared code โ reused throughout |
| Low | lib/view.js | 1 | Shared Libraries | Shared code โ reused throughout |
Key Routes
Understanding the routing structure helps you trace user interactions through the system.
API Endpoints
| Endpoint | Methods | File | Purpose |
|---|---|---|---|
query parser fn | GET | lib/request.js | Data operations |
trust proxy fn | GET | lib/request.js | Data operations |
subdomain offset | GET | lib/request.js | Data operations |
etag fn | GET | lib/response.js | Data operations |
json escape | GET | lib/response.js | Data operations |
json replacer | GET | lib/response.js | Data operations |
| +3 more | โ | โ | Additional endpoints |
How Data Flows
Understanding these flows helps you see how the system processes information end-to-end:
| Flow | Description | Key Modules |
|---|---|---|
| API Integration Flow | External service integrations and backend processing | 9 API endpoints detected |
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 express
npm install # or yarn, pnpm
2. Explore the Structure
- Review the directory structure above
- Open the
README.mdfor project-specific instructions - Look for
CONTRIBUTING.mdfor 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 mocha 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:
- Find a small bug or typo to fix
- Make the change in a feature branch
- Run tests to ensure nothing breaks
- Submit a pull request for review
Common Pitfalls
New contributors often run into these issues:
- Environment setup โ Check for
.env.examplefiles and ensure you have all required environment variables. - Branch naming โ Follow the team's branch naming conventions (usually
feature/,fix/,docs/).
Additional Resources
| Resource | Purpose |
|---|---|
README.md | Project overview and quick start |
CONTRIBUTING.md | Contribution guidelines (if exists) |
CHANGELOG.md | Recent changes and release history |
package.json | Available scripts and dependencies |
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
GraphQL Schema
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
TypeScript Type Graph
No TypeScript type declarations were detected in this repository.
RepoLens analyzes .ts and .tsx files for interface declarations, type aliases, classes, and enums. Ensure your TypeScript source directories are included in the scan.include configuration.
<!-- repolens:docs-badge -->  ยท Examples
Dependency Graph
7 files ยท 7 imports ยท 28 external packages ยท โ no circular dependencies
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
| Metric | Value |
|---|---|
| Source files | 7 |
| Import edges | 7 |
| External packages | 28 |
| Circular dependencies | 0 |
| Orphan files (no imports or importers) | 0 |
External Dependencies
The codebase imports 28 external packages. These are third-party modules (not the language standard library):
| Package |
| --------- |
accepts |
body-parser |
content-disposition |
content-type |
cookie |
cookie-signature |
debug |
depd |
encodeurl |
escape-html |
etag |
finalhandler |
fresh |
http-errors |
merge-descriptors |
mime-types |
on-finished |
once |
parseurl |
proxy-addr |
qs |
range-parser |
router |
send |
serve-static |
statuses |
type-is |
vary |
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
Architecture Drift
No baseline found. Run
repolens publishonce 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:
| Dimension | What is Tracked |
|---|---|
| Modules | New, removed, or significantly resized modules |
| API Endpoints | Added or removed backend routes |
| Dependencies | Changes to external package imports |
| Frameworks | Technology stack additions or removals |
| Circular Dependencies | Increases in dependency cycles |
| GraphQL Schema | Type additions or removals |
| Codebase Scale | Overall file count changes |
<!-- repolens:docs-badge -->  ยท Examples
Security Hotspots
No security anti-patterns were detected in the scanned source files.
RepoLens scans JavaScript and TypeScript source files for common security risks including code injection (eval), XSS (innerHTML), SQL injection, command injection, prototype pollution, hardcoded credentials, and insecure randomness.
Test files, configs, and build outputs are excluded from analysis to reduce false positives.
<!-- repolens:docs-badge -->  ยท Examples
Code Health Report
7 files analyzed ยท Average health: 78/100 ยท 3 A, 2 B, 2 C, 0 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
| Metric | Value |
|---|---|
| Files analyzed | 7 |
| Average health score | 78/100 |
| Average complexity | 33 |
| Hotspots (score < 60) | 2 |
Grade Distribution
| Grade | Count | Meaning |
|---|---|---|
| ๐ข A (80โ100) | 3 | Healthy โ low complexity, well-documented |
| ๐ต B (60โ79) | 2 | Acceptable โ minor improvements possible |
| ๐ก C (40โ59) | 2 | Needs attention โ elevated complexity or coupling |
| ๐ D (20โ39) | 0 | At risk โ multiple quality signals degraded |
| ๐ด F (0โ19) | 0 | Critical โ immediate refactoring recommended |
Hotspots โ Priority Refactoring Targets
These modules have the lowest health scores and should be prioritized for improvement:
| Module | Score | Grade | Complexity | Coupling | Doc% | Security |
|---|---|---|---|---|---|---|
lib/response.js | 45 | ๐ก C | 112 | 1โ 1โ | โ | โ |
lib/application.js | 56 | ๐ก C | 41 | 1โ 2โ | โ | โ |
Most Complex Functions
These functions have the highest cyclomatic complexity and are the most likely sources of bugs:
| Function | File | Line | Complexity |
|---|---|---|---|
send() | lib/response.js | 126 | 23 |
sendFile() | lib/response.js | 375 | 13 |
download() | lib/response.js | 437 | 13 |
acceptParams() | lib/utils.js | 89 | 12 |
compileQueryParser() | lib/utils.js | 162 | 11 |
render() | lib/application.js | 522 | 10 |
hostname() | lib/request.js | 444 | 10 |
use() | lib/application.js | 190 | 9 |
clearCookie() | lib/response.js | 715 | 8 |
onfinish() | lib/response.js | 968 | 8 |
stringify() | lib/response.js | 1026 | 8 |
View() | lib/view.js | 52 | 8 |
status() | lib/response.js | 65 | 7 |
jsonp() | lib/response.js | 264 | 7 |
header() | lib/request.js | 64 | 6 |
All Modules by Health Score
| Module | Score | Grade | Lines | Complexity | Fan-In | Fan-Out |
|---|---|---|---|---|---|---|
lib/response.js | 45 | ๐ก C | 1051 | 112 | 1 | 1 |
lib/application.js | 56 | ๐ก C | 632 | 41 | 1 | 2 |
lib/utils.js | 75 | ๐ต B | 272 | 27 | 2 | 0 |
lib/request.js | 76 | ๐ต B | 528 | 30 | 1 | 0 |
lib/view.js | 93 | ๐ข A | 206 | 17 | 1 | 0 |
index.js | 100 | ๐ข A | 12 | 1 | 0 | 1 |
lib/express.js | 100 | ๐ข A | 82 | 1 | 1 | 3 |
Scoring Methodology
The health score (0โ100) is computed from four dimensions:
| Factor | Weight | How It's Measured |
|---|---|---|
| Complexity | โ1/pt above 10, โ2/pt above 30 | Cyclomatic complexity for JavaScript/TypeScript, Python, and Go (regex, not AST) |
| Function complexity | โ2/pt above 8 per function | Highest complexity function in the file |
| Coupling | โ1/5 units above 20 | Fan-in ร Fan-out (import connections) |
| Documentation | โ10 if <50%, โ5 if <80% | JSDoc/TSDoc coverage of exports |
| Security | โ10/high, โ5/medium finding | Security anti-pattern findings in file |
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