TypeScript Formatter

TypeScript files are harder to keep readable than plain JavaScript because the types add a second layer of structure to the same lines. A conditional type spanning four levels of nesting, a generic constraint with three type parameters, or a discriminated union with eight members will each blow past the right margin and become unreadable unless something breaks them consistently. Hand-wrapping them is fiddly and never stays consistent between files.

This page runs Prettier 3.9.6 with its TypeScript parser. That parser is the largest plugin Prettier ships — roughly 200 KB gzipped, several times the size of the CSS or Markdown ones. It is lazy-loaded, so only visitors to this page pay for it; someone formatting CSS on another page never downloads it. Once fetched it is cached for the rest of your session. Everything then runs locally in a Web Worker, so no source code is uploaded.

TypeScript syntax the formatter understands

The TypeScript parser covers the whole language surface, not just annotated JavaScript:

• Type declarations. interface and type aliases, index signatures, mapped types, conditional types with extends ? :, infer, template literal types, and recursive types.
• Generics. Multiple type parameters, constraints, defaults, and const type parameters. A long parameter list breaks one parameter per line.
• Unions and intersections. A union that does not fit on one line is printed with each member on its own line, prefixed by a leading |, which is far easier to scan and to diff than a run-on line.
• Class syntax. Access modifiers, readonly, abstract, parameter properties, static blocks, ECMAScript private #fields and overload signatures.
• Decorators. Both the legacy TypeScript form and the current ECMAScript proposal form, placed on their own lines above the declaration they annotate.
• Modern operators and modifiers. satisfies, as const, non-null assertions, definite assignment, import type and export type, and inline type specifiers inside an import list.
• Enums, namespaces and module declarations, including declare module blocks and ambient declarations in .d.ts files.
• TSX. React components with typed props format correctly; the same parser handles both .ts and .tsx.

Formatting does not type-check

This is the single most important limitation, and it cuts both ways. Prettier parses your code, it does not compile it. There is no tsc here, no type checker, and no knowledge of any file other than the one you pasted.

The upside is that code with type errors formats perfectly. Assigning a string to a number, importing a symbol that does not exist, calling a method with the wrong argument count, or referencing a type from a module that was never installed — all of it parses as valid syntax and prints cleanly. That is genuinely useful when you are mid-refactor and just want the file tidy.

The downside is that a clean format tells you nothing about correctness. Only a genuine syntax error will stop the formatter, and when it does you get the message with its line and column. Everything semantic remains your compiler's job.

Why the parser is loaded only here

Prettier publishes each parser as a separate ES module precisely so that browsers can load one at a time, and this site takes that seriously. The PostCSS plugin used by the CSS pages is around 40 KB gzipped; the Markdown and GraphQL plugins are smaller still. The TypeScript plugin is about 200 KB gzipped because it embeds a substantial portion of the TypeScript grammar.

Bundling all of them together would make every page on this site pay for the heaviest one. Instead each page dynamically imports only the parsers it needs, at the moment you first press the button. That is why this page can offer full TypeScript support without slowing down the JSON formatter or the CSS minifier.

It also means the very first format here is the slowest thing you will do on the site, and every subsequent one is instant. The plugin is cached in memory for the session and by your browser's HTTP cache after that.