Format TypeScript Online: TS Beautifier

The Formatted Code

Applying the formatter to the minified TypeScript above produces:

type ApiResponse<T> = {
  data: T;
  status: number;
  message: string;
  meta: {
    page: number;
    total: number;
    hasNext: boolean;
  };
};

interface User {
  id: number;
  name: string;
  email: string;
  role: "admin" | "user" | "guest";
  preferences: {
    theme: "light" | "dark";
    language: string;
  };
}

async function fetchUsers(
  page: number = 1,
): Promise<ApiResponse<User[]>> {
  const response = await fetch(`/api/users?page=${page}`);
  if (!response.ok) {
    throw new Error(`HTTP ${response.status}`);
  }
  return response.json();
}

function filterByRole<T extends User>(
  users: T[],
  role: T["role"],
): T[] {
  return users.filter((u) => u.role === role);
}

export type { ApiResponse, User };
export { fetchUsers, filterByRole };

Each type gets its own declaration. Interfaces have one property per line. Generic type parameters are broken across lines when they exceed the print width. Union type members align vertically for scannability.

Why TypeScript Formatting Matters

TypeScript code is denser than JavaScript because of type annotations. Unformatted TypeScript with nested generics, union types, and mapped types becomes unreadable faster than equivalent JavaScript. Formatting makes several things easier:

Type review. When reviewing a function signature, you need to see each parameter and its type on its own line. A wall of type annotations in a single line makes it impossible to check individual types without manually parsing the string.

Refactoring. When renaming a type or changing a generic constraint, formatted code makes the change visible in the diff. In minified TypeScript, the same change produces a diff that spans the entire line.

Documentation. Formatted TypeScript serves as documentation. A well-formatted interface definition communicates the shape of a data structure more clearly than any comment.

TypeScript-Specific Formatting

Prettier handles TypeScript-specific constructs with the same rules as JavaScript code:

Type annotations: Broken across lines when they exceed the print width. Function parameter types, return types, and generic constraints all follow the same line-breaking rules.

Interfaces and type aliases: One property per line. Union type members can align vertically when they are short enough. Discriminated unions are formatted so the discriminant property is clearly visible.

Generics: Type parameters are broken across lines when they are long. Multi-line generics indent each type parameter on its own line.

Enums: Members are formatted one per line. Const enums follow the same rules.

Prettier vs. ESLint for TypeScript

Prettier formats code. ESLint catches bugs and enforces best practices. They serve different purposes and are complementary. A common setup:

1. Use Prettier for all formatting (semicolons, quotes, indentation, line breaks)
2. Use @typescript-eslint for type-aware linting (no-unused-vars, no-explicit-any, prefer-optional-chain)
3. Disable ESLint rules that conflict with Prettier (indent, semi, quotes)
4. Run Prettier first, then ESLint, so ESLint can fix issues that Prettier does not handle

This separation means you get consistent formatting from Prettier and code quality checks from ESLint without either tool fighting the other.