It's funny, but a large reason for why Go was chosen was explicitly because it has semantics close to TypeScript and that made it automatable:
https://github.com/microsoft/typescript-go/discussions/411#d...
> But this wasn't a compiler redesign, and the TypeScript to Go move was far more automatable and more one-to-one in its mapping.
So basically the opposite of what you're saying.
IMHO it's not the same car, even if its engine initially was a 1:1 rebuild using other alloys. But you're right I overstated and made myself look dumb (by a lot really - this is nothing like having 2 independent C compilers for instance).
What's taken 1:1, deliberately, was the compiler core. That was almost perfectly 50% of the non-test code. A close translation of that was a starting point, but open CHANGES.md or it's history and you'll see it's quickly diverging even on its surface.
The closest matching, interesting large area of it is probably the checker. Easily recognizable on a function level, even if not being a single file anymore:
https://github.com/microsoft/typescript-go/tree/main/interna...
https://raw.githubusercontent.com/microsoft/TypeScript/refs/... (The TS file is 3MB and github won't display it inline)
You'll find a lot of the same data structures (as far as that's possible in a TS-to-Go translation + ripples from areas that were more heavily changed) and functions lying around, just in slightly different places. Because of the AST changes and TS/Go differences on a line-level each function might look different, but where there is a loop in the TS one, there's probably one in Go.
The other half of the project is heavily changed or completely new/different (like concurrency, less weird language service).