| name | typedoc |
| description | Create and improve TypeScript project documentation using TypeDoc. Use when documenting TypeScript codebases, adding JSDoc comments, configuring TypeDoc, auditing documentation coverage, or generating API reference documentation for TypeScript projects. |
TypeDoc Documentation Skill
Overview
This skill provides best practices for documenting TypeScript projects using TypeDoc, from writing effective JSDoc comments to configuring and generating comprehensive API documentation.
Workflow Decision Tree
When documenting TypeScript code:
- Adding documentation to new code → Follow JSDoc Comment Standards
- Auditing existing codebase → Use Documentation Audit workflow
- Setting up TypeDoc → Follow Configuration Setup
- Improving existing docs → Review Common Patterns and apply to problem areas
JSDoc Comment Standards
Core Principles
Write documentation that adds value beyond what the code shows. Avoid stating the obvious.
Good: Explains why, edge cases, usage constraints
function validateInput(input: string): string;
Avoid: Repeating what TypeScript types already show
function validateInput(input: string): string;
Essential Tags
Use these TypeDoc/JSDoc tags appropriately:
@param - Document each parameter (required for functions)
async function fetchUser(userId: string, options?: QueryOptions);
@returns - Explain what's returned and when (required for non-void functions)
async function fetchUser(userId: string): Promise<User | null>;
@throws - Document exceptions that callers should handle
function registerUser(email: string, password: string);
@example - Show realistic usage (highly valuable)
@deprecated - Mark obsolete code with migration path
function getUser(id: string);
@see - Link to related functions or documentation
@remarks - Add detailed explanations or important notes
What to Document
Always document:
- Public APIs and exported functions/classes
- Complex business logic or algorithms
- Non-obvious behavior or edge cases
- Functions that throw errors
- Configuration objects with many options
Usually document:
- Interfaces and type aliases (brief description of purpose)
- Class methods (especially public ones)
- Callback parameters (explain when/how they're called)
Sometimes skip:
- Private implementation details (unless complex)
- Self-explanatory getters/setters
- Simple utility functions where name + types are sufficient
Specific Patterns
Classes and Constructors
class ConnectionManager {
constructor(config: ConnectionConfig) {}
}
Interfaces and Types
interface PoolConfig {
maxConnections?: number;
idleTimeout: number;
}
Generic Functions
function map<T, R>(items: T[], mapper: (item: T) => R): R[];
Function Overloads
function fetch(url: string): Promise<Response>;
function fetch(config: RequestConfig): Promise<Response>;
function fetch(urlOrConfig: string | RequestConfig): Promise<Response> {
}
Async Functions
async function fetchUser(userId: string): Promise<User>;
Enums
enum AuthState {
Anonymous = 'ANONYMOUS',
Authenticated = 'AUTHENTICATED',
Expired = 'EXPIRED',
}
Configuration Setup
Basic typedoc.json
Create typedoc.json in project root:
{
"$schema": "https://typedoc.org/schema.json",
"categorizeByGroup": true,
"entryPoints": ["./src/index.ts"],
"excludeInternal": true,
"excludePrivate": true,
"excludeProtected": false,
"navigation": {
"includeCategories": true,
"includeGroups": true
},
"out": "docs",
"plugin": [],
"readme": "README.md"
}
Common Configuration Options
entryPoints - Starting files for documentation
- Single entry:
["./src/index.ts"]
- Multiple modules:
["./src/api/index.ts", "./src/utils/index.ts"]
- Glob patterns:
["./src/**/*.ts"]
excludePrivate/excludeProtected/excludeInternal - Control visibility
excludePrivate: true - Hide private members (recommended)
excludeInternal: true - Hide @internal tagged items
- Keep protected members visible for inheritance docs
categorizeByGroup - Organize by @group tags
export function login() {}
export function createUser() {}
Package.json Scripts
{
"scripts": {
"docs": "typedoc",
"docs:json": "typedoc --json docs.json",
"docs:watch": "typedoc --watch"
}
}
Documentation Audit Workflow
When auditing a codebase for documentation coverage:
- Generate JSON output to analyze programmatically:
npx typedoc --json docs.json
-
Identify undocumented exports:
- Look for exported functions/classes without comments
- Check for missing @param or @returns tags
- Find functions that throw errors without @throws
-
Prioritize documentation:
- Start with public API surface (exported items)
- Focus on complex functions with multiple parameters
- Document functions that throw errors or have side effects
-
Common gaps to check:
- Generic type parameters without @typeParam
- Callback parameters without explanation
- Optional parameters without default value explanation
- Return types that need context (e.g., null vs undefined)
Advanced Patterns
Module Organization
Use @module for file-level documentation:
Cross-References
Link between related items:
function createUser(email: string): User;
Inline Type Documentation
Document complex inline types:
function query(options: { sort?: string; filter?: Record<string, any> });
Custom Tags
Define custom tags in typedoc.json for domain-specific needs:
{
"customTags": ["performance", "security"]
}
Use in code:
function processData(data: string[]);
Quality Guidelines
Write for Developers
Assume the reader knows TypeScript but not your domain:
- Explain business logic and "why"
- Document non-obvious behavior
- Highlight edge cases and gotchas
- Show realistic usage examples
Keep It Current
- Update docs when changing function signatures
- Remove outdated examples
- Mark deprecated items immediately
- Version migration notes in @deprecated tags
Consistency Matters
- Use consistent terminology across the codebase
- Follow a standard order: description → @param → @returns → @throws → @example
- Use active voice: "Returns the user" not "The user is returned"