TypeScript Formatter

TypeScript is a superset of JavaScript, but the type-level syntax it adds — interfaces, generics constrained with `extends`, decorators, `as` type assertions, and standalone type-only declarations — has no meaning in plain JavaScript grammar and causes a JavaScript-only parser to fail outright on perfectly valid TypeScript. Using the dedicated TypeScript parser rather than trying to force the JavaScript one to accept a superset of its own grammar is what lets a file full of generics and interfaces format correctly rather than being rejected as a syntax error the moment it uses a feature JavaScript itself does not have.

A `.tsx` file combining JSX syntax with TypeScript's type annotations is genuinely ambiguous to parse in one particular spot: an angle-bracket type assertion like `<Foo>value` looks identical to the start of a JSX element tag to a parser that has not been told which dialect it is reading. Selecting the TypeScript-with-JSX parsing mode resolves that ambiguity correctly, which is why choosing the right dialect up front — rather than assuming a generic JavaScript parser will figure it out — matters specifically for component files that mix the two.

Decorators — the `@Component` style annotations common in Angular and in some backend frameworks built on TypeScript — have gone through several different proposal stages in the language's standardisation process, and different codebases can be targeting slightly different versions of that syntax depending on when they were written and which compiler options they use. Parsing decorator syntax correctly requires the TypeScript-aware parser specifically; a plain JavaScript parser encountering an `@` before a class or method has no defined meaning to fall back on and will reject the file outright.