TypeScript 7 (TS-Go) support

[Gerrit0]

This is the tracking issue for support for TypeScript's port to Go.

Updating to TypeScript 7 is unfortunately not an easy change for TypeDoc as:

1. The TypeScript 7 API is a complete rewrite from the TypeScript 6 and prior APIs.
2. TypeDoc heavily depends on some internal features in TypeScript 6 which are not present in the TypeScript 7 API.

The plan today is to perform a feature freeze once TypeScript 7.0 has released. At that time, additional feature requests will be put on hold until after the necessary changes to support TypeScript 7 have been made. Bug fixes will likely also be limited to critical issues.

There is no timeline for how long this will take. I work on TypeDoc during my free time during the weekends, usually an hour or two per week. If your company has a pressing need for TypeDoc to support TypeScript 7 and would like to sponsor faster development, please reach out.

[samchon]

@Gerrit0 May I challenge this issue with AI coding?

I've fully migrated typia to tsgo, and also built ttsc with Codex and a handful of prompt snippets.

Honestly, without tools like Claude Code or Codex, I think I would've given up on the typia migration partway through - the surface area was just too large to chew through manually on weekends.

For people like you and me who can only spare a few hours a week, I think AI coding is realistically the only way to keep up with breaking changes of this scale.

Migration Plan

Given the size of the rewrite, I don't think this can be incremental. It would have to land as a single migration PR. To make that PR trustworthy, I'd expand the test suite significantly beforehand, so the migration is validated against a much tighter safety net than what exists today.

I'd also battle-test the migrated version against my own projects first - typia, nestia, and a few others - which together exercise a fairly wide range of TypeScript's type system. Only after it survives those would I open the PR.

Long-Term: Playground Mode

One more thing, if you're open to it: I'd like to eventually contribute a playground mode to TypeDoc, as a separate PR sometime after the tsgo migration settles. No timeline, just flagging the direction.

typia.io/playground currently bundles tsgo + ttsc + typia into a single WebAssembly build, so users can try the whole toolchain in-browser. Something similar for TypeDoc would, I think, help library authors a lot - previewing generated docs live while writing JSDoc, without running a full build, would shorten the iteration loop quite a bit.

That said, I don't have a concrete design for how this fits into TypeDoc's architecture yet. I'd really value your input on the API surface and where the boundaries should sit - what to expose, how to decouple rendering from filesystem I/O, that sort of thing. So this is less a proposal and more a direction I'd like to explore with you, if it sounds interesting at all.

Closing

You'd be the sole decision-maker on whether any of this lands. No pressure either way - just wanted to ask before going the fork route.