You still need a full JS(x) parser (and lexer) though since / symbols are contextual (as are < in JSX).
/ and < in operator positions becomes operators, whilst / in plain JS in a value position becomes the start of an reg-exp and < becomes the start of an JSX tag, so to handle it there needs to be a full parser (with a pull-lexer to correctly handle the contextual part) as you cannot just do a textual replacement due to ambiguity.
Typescript supports JSX out of the box. It was once true you need custom tools for React, but JSX has proven useful enough that support is provided almost anywhere you need it. Also, as someone else mentioned, JSX is really just syntactic sugar around vanilla JS, so supporting it is much easier.
You don't, because JSX is not required for react. This isn't even just a theoretical point, but something I've actually done in the past several times; it's very convenient to just try something out by throwing react into a script tag and then just writing a small prototype or something without utilizing JSX and thus avoiding the need to set up a build system and everything else. I would still use JSX for larger projects, of course, but it is mostly just a small quality-of-life improvement, and I'd be using react even if JSX didn't exist, as the actually important parts of the library are not about JSX.
> You don't, because JSX is not required for react.
And what does this have to do with the fact that the absolute vast majority of react code is written with JSX and that you need special tools in IDEs to deal with React code (because regular JS tools would break)?