TL;DR

이 레포지토리는 framework나 CLI를 새로 제공하는 도구가 아니라, TypeScript 생태계의 classic `typescript` 패키지를 tsgo 7.0.2 기반 구현으로 교체하는 library-SDK 성격의 bridge입니다. `typescript` override 하나로 `vue-tsc`, `svelte-check`, `astro-check`, `glint`, ESLint, `tsserver`를 기존 API와 설정 그대로 연결하며, Go checker가 병목인 전체 프로그램 검사에서 특히 빠릅니다. 실제 측정에서 `vue-tsc -b`는 약 2,000개 파일 기준 9.7초에서 3.2초가 됐지만, ESLint 단일 실행은 거의 동일하고 전체 RSS는 증가했습니다. Alpine/musl, custom module resolver, stock TypeScript와 다른 tsgo 진단을 감수해야 하므로 glibc 환경의 대형 TypeScript·Vue monorepo에서 먼저 측정한 뒤 도입하는 편이 안전합니다.

핵심 포인트

• TypeScript 7의 Go 기반 tsgo 엔진을 classic `typescript` API 뒤에 연결하는 drop-in 대체 패키지입니다. `typescript` 의존성만 override하면 `tsc`, `vue-tsc`, `svelte-check`, `astro-check`, `glint`, ESLint, `tsserver`가 기존 설정과 코드로 작동합니다. TypeScript 7의 새 API나 별도 LSP로 마이그레이션하기 어려운 프로젝트에 맞습니다.
• JavaScript와 Go 사이의 in-process cgo NAPI/FFI bridge를 사용해 IPC 없이 검사 요청을 처리합니다. 프로그램 파일을 필요할 때 지연 생성하고, 언어 서비스 요청에는 고정 레이아웃 V8 메모리 transport와 메모이제이션을 적용합니다. `vue-tsc -b`에서는 약 2,000개 파일 기준 9.7초에서 3.2초로 줄었지만 전체 프로세스 RSS는 1.8GB에서 3.3GB로 증가했습니다.
• `pnpm`은 workspace root의 `overrides`와 `catalog`를 함께 바꿔야 하며, npm은 alias와 `$typescript` override 조합을 사용해야 합니다. CLI는 의존성 override만으로 적용되지만 VS Code와 Cursor는 workspace TypeScript 경로를 지정하고 Use Workspace Version을 선택해야 합니다. 첫 type-check 때 stderr에 `TNB ACTIVE`가 출력되는지와 `require.resolve('typescript')` 경로로 실제 적용 여부를 확인합니다.
• macOS, glibc 기반 Linux, Windows의 주요 x64·arm64 플랫폼용 optional dependency를 제공하지만 Alpine/musl은 Go c-shared 런타임 문제로 지원하지 않습니다. `resolveModuleNames`나 `resolveModuleNameLiterals`로 import를 다른 실제 파일에 재매핑하는 custom resolver도 동작하지 않습니다. tsgo 7.0.2의 진단과 bundled libs를 그대로 따르므로 stock TypeScript 6.0.3과 결과가 달라질 수 있어 자체 저장소에서 먼저 측정해야 합니다.

벤치마크