API documentation covers exports

TypeScript types tell consumers what parameters exist; JSDoc tells them what those parameters mean, when to use the function, and what edge cases to watch for. A package with zero API documentation forces every consumer to read your source code or experiment by trial and error. ISO 25010 analysability is the directly impacted quality attribute: the time to understand and correctly use your API is the measure. For SDK packages that wrap external services, undocumented error conditions and edge cases are the primary source of consumer integration bugs.

Add TSDoc comments to every exported function, class, and type. These render automatically in VS Code and other IDEs without any additional tooling.

/**
 * Creates a new API client instance.
 *
 * @param config - Client configuration. `apiKey` is required; `timeout` defaults to 10 000ms.
 * @returns A configured client ready to make requests.
 * @throws {ApiError} When the server returns a 4xx or 5xx response.
 *
 * @example
 * ```ts
 * const client = createClient({ apiKey: 'sk-...' })
 * const users = await client.request<User[]>('/users')
 * ```
 */
export function createClient(config: ClientConfig): Client {}

At least 80% of public API functions must have JSDoc. For larger packages, generate a docs site: npx typedoc --out docs src/index.ts.

• ID: sdk-package-quality.docs-maintenance.api-reference

• Severity: low

• What to look for: Enumerate every public function, class, and type exported by the SDK. For each, check for API documentation that covers the package's exported functions, classes, and types. Look for:

  1. Inline TSDoc/JSDoc comments on exported symbols in source code
  2. A dedicated docs/ directory or API.md file
  3. Generated API docs (TypeDoc, documentation.js, etc.)
  4. README sections that cover each major export
  5. Whether the documentation matches the current API (not outdated)

• Pass criteria: At least one form of API documentation exists that covers the primary exports — either JSDoc/TSDoc comments on exported functions/classes, a docs site, an API reference file, or comprehensive README sections with parameter descriptions — at least 80% of public API functions must have JSDoc or equivalent documentation. Report: "X public APIs found, Y documented with examples."

• Fail criteria: No API documentation of any kind. Exported functions have no JSDoc comments, no docs directory, no API reference. The only way to understand the API is to read the source code.

• Skip (N/A) when: The package has 3 or fewer exports, each of which is self-documenting through TypeScript types (e.g., a single function with well-named parameters and return type). The types themselves serve as documentation.

• Detail on fail: "No JSDoc comments on any of the 12 exported functions. No docs/ directory, no API.md, no TypeDoc config. The only way to understand createClient(), configure(), and resetState() is to read the source."

• Remediation: API docs let consumers use your package without reading its source. TSDoc comments are the lowest-effort approach — they show up in IDE tooltips automatically.

  /**
   * Creates a new API client instance.
   *
   * @param config - Client configuration options
   * @returns A configured client ready to make requests
   *
   * @example
   * ```ts
   * const client = createClient({ apiKey: 'sk-...' })
   * const users = await client.list('users')
   * ```
   */
  export function createClient(config: ClientConfig): Client {
    // ...
  }
  

  For larger packages, consider generating docs with TypeDoc: npx typedoc --out docs src/index.ts.