What TypeDoc Includes from a TypeScript Entry Point

TypeDoc’s starting point for an API reference is the exports of each entry point. It follows re-exports, so a declaration can appear in the reference even when it is defined in another file. For a library maintainer, the useful question is not just “Which files contain documentation comments?” but “Which names does the chosen entry point expose?” TypeDoc’s documentation describes this export-based behavior.

Read the entry point as the documentation boundary

Suppose a small library exposes its API through src/index.ts:

// src/index.ts

/** A session identified by a caller-supplied ID. */
export interface Session {
  id: string;
}

export { createSession } from "./createSession";

The re-exported function is declared in a second file:

// src/createSession.ts

/** Create a session with the given ID. */
export function createSession(id: string): Session {
  return { id };
}

That second snippet needs an import for Session to be a complete TypeScript file. To keep the two-file example self-contained, add the import at the top of src/createSession.ts:

import type { Session } from "./index";

With src/index.ts as the entry point, expect the generated result to represent both Session and createSession. Session is exported where it is declared; createSession reaches the entry point through a re-export. TypeDoc’s documented behavior is to follow that re-export to a member declared in another file. There is no need to treat the function’s file as a separate entry point merely to account for this export.

This example makes a useful review question concrete: does the entry module export the names you intend readers to find? If you expected another declaration, trace whether it is exported directly or re-exported through the chosen entry point. Also look for names you did not mean to expose. That inspection tells you what the module presents; the generated result tells you what TypeDoc represented. Neither check decides whether the API is well designed.

Check names and comments separately

Once you have generated documentation for that entry point, look for Session and createSession. The function is the important re-export check: its presence shows that the result includes a declaration from src/createSession.ts, reached through src/index.ts. If a name is absent, inspect the entry module and the relevant export path before assuming its comment is the problem. Absence is an observation, not a diagnosis of why the name is missing.

Then inspect the text attached to each declaration. TypeDoc converts comments in TypeScript source into documentation, so the example gives you two distinct expectations: the session description belongs with Session, and the creation description belongs with createSession. A present name with missing or unexpected text calls for a comment review, even if the export check passed.

This is a representation check, not a correctness test. Seeing “Create a session with the given ID” in the output does not prove that the sentence gives callers enough guidance. If several documentation tools must read the same comments, TSDoc describes a proposal for consistent TypeScript documentation-comment syntax; deciding what a comment should say remains a separate task.

Choose the output you need to inspect

TypeDoc can turn source comments into HTML documentation or a JSON model. HTML is the output to inspect when the deliverable is a reference people will browse. Check the displayed declarations and their descriptions as a reader would. JSON is documentation data for a downstream consumer, not itself the browsable reference; inspect it for the expected represented members and extracted comments rather than judging it as a set of pages.

The same narrow acceptance test applies to either output: are the entry point’s expected exports represented, including the member re-exported from another file, and were their source comments extracted? Those answers establish what the generated result contains. They do not establish that the descriptions are accurate or useful.

For installation steps and the configuration or command syntax needed to generate either output, consult the documentation for the TypeDoc release you use. The export and comment checks above apply after you have selected an entry point; they are not a substitute for that release’s setup instructions.