TypeScript Formatter
Run Prettier over TypeScript with the TypeScript parser selected, which is required - feeding annotated code to the Babel parser fails on the first type annotation.
This page opens with that parser already chosen.
Why the parser choice matters here
Prettier normally picks a parser from the file extension, and a pasted snippet has none. Type annotations, interfaces, generics, enums and decorators are all syntax the JavaScript parser does not accept, so the wrong selection produces a parse error rather than badly formatted output.
Long generic signatures
Type-heavy code hits the print width quickly, and Prettier breaks generic parameter lists one per line once they no longer fit. That is often the point at which a signature is telling you the type is doing too much - the formatting is a symptom rather than the problem.
Type-only imports and decorators
Prettier preserves the import type distinction rather than collapsing it into a value import, which matters because the two compile differently under isolatedModules and verbatimModuleSyntax.
Decorators are formatted onto their own line above the declaration they annotate, which is the convention Angular and NestJS codebases already follow. If your project keeps short decorators inline, that is one of the choices Prettier removes.
Formatting does not typecheck
Prettier parses TypeScript syntax but ignores its meaning entirely. Code with a genuine type error formats perfectly, because the formatter only needs a valid syntax tree.
So a clean format is not a signal that anything compiles. Run tsc for that; the two tools answer completely different questions about the same file.