Publish compiler Go packages and automate upstream updates - #1

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

💡 Codex Review

Run the complete compiler test suite

This is now the only source regression command after the full CI workflow was deleted, so it executes tests for just four packages; as go help test documents, it tests “the packages named by the import paths.” Tests in checker, parser, binder, emit transforms, module resolution, and thousands of other compiler packages—including the changed internal/checker/tracer_test.go—will never run. Consequently, a weekly upstream merge can pass validation and be published while breaking most of the exported compiler surface; run the source module's complete test suite (and retain the existing baseline/generation checks) before release.

Rewrite the copied fswatch import example

External consumers following this newly published package README are told to import the original tsc/internal/fswatch path, which Go rejects from outside the Microsoft module tree. The example needs to use github.com/zshannon/TypeScript/public/v7/fswatch (and the exporter should rewrite copied textual documentation) so the documented public-package flow actually compiles.

Decision on the two review findings: neither is a merge blocker for this fork, and we are not expanding this PR to address them.

1. Full compiler suite: this fork relies on Microsoft's upstream compiler testing. Our validation is intentionally focused on what we change: package export generation, import rewriting, embedded assets, external consumption, and targeted compiler modifications. Running the entire upstream suite could provide additional assurance against integration regressions, but we are accepting that tradeoff rather than making it a release requirement or restoring upstream CI. The finding identifies reduced coverage, not a demonstrated regression.

2. Copied fswatch README: the upstream internal import in the example is stale for external consumers, but it does not affect the exported package's functionality. Rewriting copied documentation is not a requirement for this fork's intended use, so we are leaving it as non-blocking documentation cleanup.

The scope remains publishing usable compiler packages with focused validation of the fork's changes.