TypeScript 7.0 발표

 (devblogs.microsoft.com)
1P by GN⁺ | ★ favorite | 댓글 2개
  • TypeScript 7.0은 도구체인을 Go 기반 네이티브 코드로 이식한 릴리스로, 대형 프로젝트의 전체 빌드에서 보통 8~12배 속도 향상을 제공함
  • 새 tsc는 기존처럼 npm의 typescript 패키지로 설치하며, 편집기 지원은 LSP 기반 언어 서버로 VS Code, Visual Studio, WebStorm 등에서 동작함
  • vscode, sentry, bluesky, playwright, tldraw 같은 코드베이스에서 빌드 시간이 크게 줄었고, 일부 환경에서는 총 메모리 사용량도 낮아짐
  • TypeScript 7.0은 아직 안정적인 프로그래밍 API가 없어 typescript-eslint, Vue, MDX, Astro, Svelte, Angular 템플릿 타입 검사 등 TypeScript를 내장하는 도구는 TypeScript 6.0 병행이 필요함
  • 새 기본값과 제거된 옵션이 있어 TypeScript 6.0 변경 사항을 먼저 적용하는 편이 전환에 유리하며, TypeScript 7.1에서 새 API 제공이 예정됨

Go 기반 네이티브 TypeScript

  • TypeScript 7.0은 TypeScript 도구체인의 네이티브 포트로, Go로 작성된 새 코드베이스를 사용함
  • 기존 코드베이스의 구조와 로직을 최대한 유지해 두 컴파일러 간 결과의 일관성과 호환성을 맞추는 방향으로 포팅됨
  • 새 코드베이스는 네이티브 코드 속도, 공유 메모리 기반 멀티스레딩, 여러 최적화를 통해 전체 빌드에서 보통 8~12배 빠른 결과를 냄
  • 설치는 기존처럼 npm으로 가능함
npm install -D typescript
  • 설치 후 워크스페이스에서 새 tsc 실행 파일을 사용할 수 있으며, npx tsc로 실행 가능함

개발 피드백 루프 단축

  • TypeScript는 편집기 로딩, 전체 참조 찾기, 자동 완성, 진단, tsc, --watch 모드 등 개발 과정 여러 단계에 관여함
  • TypeScript 7은 이 과정 전반의 대기 시간을 줄여 피드백 루프를 짧게 만듦
  • VS Code 코드베이스에서 오류가 있는 파일을 열었을 때 첫 오류가 보이기까지 걸리는 시간은 약 17.5초에서 1.3초 미만으로 줄어 13배 이상 빨라짐
  • 편집기 지원은 LSP 기반이며, 새 언어 서버는 멀티스레딩을 활용해 동시 요청을 빠르게 처리함
  • VS Code 사용자는 TypeScript 7 전용 확장을 설치할 수 있고, 향후 몇 주 안에 VS Code 자체에도 TypeScript 7 지원이 포함될 예정임
  • Visual Studio 최신 버전은 워크스페이스에 따라 TypeScript 7을 자동 활성화함

빌드 성능과 메모리 결과

  • TypeScript 6과 7을 대형 오픈소스 코드베이스에서 비교한 전체 빌드 시간은 다음과 같음
코드베이스 TypeScript 6 TypeScript 7 속도 향상
vscode 125.7초 10.6초 11.9배
sentry 139.8초 15.7초 8.9배
bluesky 24.3초 2.8초 8.7배
playwright 12.8초 1.47초 8.7배
tldraw 11.2초 1.46초 7.7배
  • 같은 빌드에서 TypeScript 7은 대체로 총 메모리 사용량도 더 낮았음
코드베이스 TypeScript 6 TypeScript 7 메모리 변화
vscode 5.2GB 4.2GB -18%
sentry 4.9GB 4.6GB -6%
bluesky 1.8GB 1.3GB -26%
playwright 1.0GB 0.9GB -11%
tldraw 0.6GB 0.5GB -15%

실제 코드베이스 검증과 팀 피드백

  • TypeScript 프로젝트는 10년 이상 누적된 수만 개 테스트를 모든 main 브랜치 커밋에서 실행함
  • TypeScript 7은 이 테스트 외에도 내부·외부 대형 팀의 실제 코드베이스에서 검증됨
  • Microsoft 내부에서는 Loop, Office, PowerBI, Teams, Xbox 팀이 TypeScript 7을 검증함
  • 외부에서는 Bloomberg, Canva, Figma, Google, Lattice, Linear, Miro, Notion, Sentry, Slack, Vanta, Vercel, VoidZero 등이 코드베이스에서 테스트하고 피드백을 제공함
  • 새 언어 서버는 TypeScript 6.0 대비 실패한 언어 서버 명령을 80% 이상, 서버 크래시를 60% 이상 줄임
  • 실제 팀 피드백에는 다음 사례가 포함됨
    • Slack은 TypeScript 7로 merge queue 시간이 40% 줄었고, CI 타입 검사 시간이 약 7.5분에서 1.25분으로 낮아졌다고 전함
    • Vanta는 큰 프로젝트 중 하나에서 최대 9배 빌드 속도 향상을 보임
    • Microsoft News Services 팀은 CI 빌드 대기 시간을 월 400시간 절감함
    • Canva는 편집기에서 첫 오류가 보이기까지 걸리는 시간이 약 58초에서 4.8초로 줄었다고 전함

TypeScript 6.0과 병행 실행

  • TypeScript 7.0은 아직 API를 포함하지 않음
  • TypeScript 7.1에서 새롭고 다른 API를 제공할 예정임
  • 그 전까지 컴파일러에 대한 프로그래밍 접근이 필요한 도구를 위해 TypeScript 6.0과 7.0을 병행 실행할 수 있음
  • 새 호환성 패키지 @typescript/typescript6는 tsc6 실행 파일을 제공하고 TypeScript 6.0 API를 다시 내보냄
  • typescript-eslint처럼 peer dependency로 typescript를 직접 import하는 도구에는 npm alias 사용을 권장함
npm install -D typescript@npm:@typescript/typescript6
  • TypeScript 6 API와 TypeScript 7의 tsc를 함께 쓰려면 다음처럼 alias를 둘 수 있음
{
  "devDependencies": {
    "@typescript/native": "npm:typescript@^7.0.2",
    "typescript": "npm:@typescript/typescript6@^6.0.2"
  }
}
  • 기존 @typescript/native-preview 패키지는 TypeScript 7 새 코드베이스의 nightly 빌드를 제공해 왔고, 주간 다운로드가 850만 회 이상이었음
  • 앞으로 nightly 빌드는 표준 typescript 패키지의 next 태그로 재개될 예정임
npm install -D typescript@next

병렬화 제어 옵션

  • TypeScript 7.0은 파싱, 타입 검사, emit 등 여러 단계를 병렬 실행함

  • 파싱과 emit은 파일별로 독립 실행이 쉬워 큰 코드베이스에서 비교적 적은 오버헤드로 확장됨

  • 새 실험적 플래그 --checkers, --builders, --singleThreaded가 병렬화 동작을 조정함

  • --checkers

    • TypeScript 7.0은 고정된 수의 타입 검사 워커를 만들고, 같은 입력 파일에 대해 항상 동일하게 작업을 나눠 동일한 결과를 내도록 함
    • 기본 타입 검사 워커 수는 4개이며, --checkers로 조정 가능함
    • --checkers 8을 사용한 같은 머신의 결과는 다음과 같음
    코드베이스 TypeScript 6 TypeScript 7 --checkers 8 속도 향상
    vscode 125.7초 7.51초 16.7배
    sentry 139.8초 12.08초 11.6배
    bluesky 24.3초 2.01초 12.1배
    playwright 12.8초 1.16초 11배
    tldraw 11.2초 1.06초 10.6배
    • --checkers를 늘리면 더 많은 CPU 코어를 활용해 빌드가 빨라질 수 있지만, 보통 메모리 사용량 증가가 따름
    • CPU 코어와 메모리가 적은 CI runner에서는 값을 낮춰 불필요한 오버헤드를 피할 수 있음
    • --checkers 1은 타입 검사를 사실상 단일 스레드로 만들고 중복 작업을 제거함
    • 드문 경우 --checkers 수 변화가 순서 의존 결과를 드러낼 수 있어, 빌드 환경 전반에서 고정된 checker 수를 지정하는 방식이 도움이 될 수 있음

  • --builders

    • --builders는 --build 실행 시 동시에 실행할 수 있는 프로젝트 참조 빌더 수를 제어함
    • 프로젝트가 많은 monorepo에서 특히 도움이 될 수 있음
    • 값을 늘리면 빌드가 빨라질 수 있지만 메모리 사용량도 증가할 수 있음
    • --checkers와 곱셈 효과가 있어 --checkers 4 --builders 4는 최대 16개 타입 검사기가 동시에 실행될 수 있음
    • --builders 수 변화는 --checkers와 달리 다른 결과를 만들지 않아야 함
    • 프로젝트 참조 빌드는 기본적으로 프로젝트 의존성 그래프에 의해 병목이 생김

  • --singleThreaded

    • --singleThreaded는 컴파일러 전체를 단일 스레드로 실행하게 함
    • 디버깅, TypeScript 6과 7의 성능 비교, 외부 병렬 빌드 오케스트레이션, 리소스가 매우 제한된 환경에서 유용할 수 있음
    • 이 플래그는 타입 검사 워커 수를 1로 제한할 뿐 아니라 파싱과 emit도 단일 스레드에서 수행하게 함

새 --watch 모드

  • TypeScript 7은 --watch 모드를 완전히 다시 만들었음
  • 새 --watch는 Parcel bundler의 file-watcher를 기반으로 효율적이고 안정적인 크로스플랫폼 파일 감시 기능을 제공함
  • Go 표준 라이브러리에는 내장 파일 감시 API가 없고, 검토한 서드파티 라이브러리들은 안정성, 성능, 크로스플랫폼 지원, 빌드 도구 통합에서 문제가 있었음
  • 순수 polling 방식은 여러 운영체제에서 동작했지만, node_modules 의존성이 많은 대형 프로젝트에서는 계산 비용이 컸음
  • TypeScript 팀은 VS Code에서 쓰여 온 @parcel/watcher를 Go로 포팅했고, C++ 툴체인 의존성을 피하기 위해 최소한의 어셈블리 shim을 사용함
  • 이 watcher는 독립 패키지이며, TypeScript 7의 --watch 모드에서 플랫폼 전반의 리소스 사용 개선을 가져옴

TypeScript 6.0 기본값과 호환성 변화

  • TypeScript 7.0은 TypeScript 6.0의 타입 검사와 명령줄 동작과 호환되도록 만들어짐
  • stableTypeOrdering 플래그가 켜져 있고 ignoreDeprecations가 설정되지 않은 상태에서 TypeScript 6.0으로 깨끗하게 컴파일되는 코드는 TypeScript 7.0에서도 동일하게 컴파일되어야 함
  • TypeScript 7.0은 TypeScript 6.0의 새 기본값을 채택하고, TypeScript 6.0에서 deprecated된 플래그와 구문에는 hard error를 냄
  • 주요 설정 기본값 변화는 다음과 같음
    • strict 기본값은 true
    • module 기본값은 esnext
    • target 기본값은 esnext 직전의 현재 안정 ECMAScript 버전
    • noUncheckedSideEffectImports 기본값은 true
    • libReplacement 기본값은 false
    • stableTypeOrdering 기본값은 true이며 끌 수 없음
    • rootDir 기본값은 ./
    • types 기본값은 []이며, 이전 동작은 ["*"]로 복원 가능함
  • rootDir과 types 변화가 가장 놀라울 수 있는 변경으로 꼽힘
    • tsconfig.json이 src 같은 소스 디렉터리 밖에 있는 프로젝트는 기존 디렉터리 구조 유지를 위해 rootDir을 명시해야 함
    • 특정 전역 선언에 의존하는 프로젝트는 필요한 @types 패키지를 types에 명시해야 함
{
  "compilerOptions": {
    "rootDir": "./src"
  },
  "include": ["./src"]
}

{
  "compilerOptions": {
    "types": ["node", "jest"]
  }
}

제거되거나 hard error가 된 동작

  • TypeScript 7.0에서는 TypeScript 6.0에서 deprecated된 여러 옵션과 구문이 더 이상 지원되지 않음
  • 주요 항목은 다음과 같음
    • target: es5 미지원
    • downlevelIteration 미지원
    • moduleResolution: node/node10 미지원, nodenext와 bundler 권장
    • module: amd, umd, systemjs, none 미지원, bundler 또는 브라우저 기반 모듈 해석과 함께 esnext나 preserve 권장
    • baseUrl 미지원, paths는 baseUrl 대신 프로젝트 루트 기준 상대 경로로 업데이트 가능함
    • moduleResolution: classic 미지원, bundler 또는 nodenext 권장
    • esModuleInterop과 allowSyntheticDefaultImports는 false로 설정할 수 없음
    • alwaysStrict는 true로 간주되며 false로 설정할 수 없음
    • namespace 선언에서 module 키워드 사용 불가
    • import에서 asserts 키워드 사용 불가, ECMAScript import attribute 문법 변화에 맞춰 with 사용 필요
    • skipDefaultLibCheck 아래에서 /// <reference no-default-lib /> 지시문은 더 이상 존중되지 않음
    • 현재 디렉터리에 tsconfig.json이 있으면 명령줄 빌드에서 파일 경로를 받을 수 없고, 명시적 --ignoreConfig가 필요함

템플릿 리터럴 타입과 JavaScript 지원 변화

  • TypeScript 7.0은 템플릿 리터럴 타입 추론에서 Unicode code point를 더 자연스럽게 처리함
type HeadTail<S> = S extends `${infer Head}${infer Tail}` ? [Head, Tail] : never;

type Result = HeadTail<"😀abc">;
// 7.0: ["😀", "abc"]
// 이전: ["\ud83d", "\ude00abc"]
  • 이전에는 JavaScript의 UTF-16 indexing 동작을 따라 "😀"를 surrogate pair의 두 부분으로 나눴음
  • 새 동작은 for...of나 [...str]처럼 "😀"를 하나의 단위로 다루는 직관에 맞음
  • UTF-16 code unit을 의도적으로 모델링한 타입 수준 문자열 조작에는 breaking change가 될 수 있음
  • JavaScript 지원은 TypeScript 파일 분석 방식과 더 일관되도록 재작업됨
    • 타입 위치에서 값을 사용할 수 없고 typeof someValue를 써야 함
    • @enum은 더 이상 특별 취급되지 않음
    • 단독 ?는 타입으로 사용할 수 없고 any를 써야 함
    • @class는 함수를 생성자로 만들지 않으며 class 선언을 써야 함
    • postfix !는 지원되지 않음
    • 타입 이름은 @typedef 태그 안에서 정의해야 함
    • Closure 스타일 함수 문법은 더 이상 지원되지 않고 TypeScript 축약 문법을 써야 함
  • this aliasing과 함수 prototype 전체 재할당 같은 일부 JavaScript 패턴도 더 이상 특별 취급되지 않음
  • TypeScript 6.0과 7.0의 차이는 CHANGES.md에 더 자세히 정리되고 있음

편집기 기능과 제한

  • TypeScript 7.0에는 beta 이후 누락됐던 여러 편집기 기능이 추가됨
  • 자동 import, 확장 가능한 hover, inlay hint, code lens, go-to-source-definition, JSX linked editing, tag completion 등이 포함됨
  • semantic highlighting, “sort imports”, “remove unused imports” 등 TypeScript 7.0 beta에서 빠졌던 기능도 들어옴
  • 언어 서버 품질을 위해 테스트와 진단 인프라를 재구축했고, GitHub의 주요 TypeScript·JavaScript 코드베이스를 대상으로 fuzz test를 수행할 수 있음

내장 언어 워크플로의 현재 제약

  • Vue, MDX, Astro, Svelte 등을 사용하는 워크플로는 아직 TypeScript 7을 활용하지 못할 가능성이 높음
  • Angular 템플릿 같은 특수 템플릿 타입 검사도 TypeScript 7을 사용하지 못할 가능성이 높음
  • 주된 이유는 TypeScript 7이 아직 안정적인 프로그래밍 API를 노출하지 않기 때문임
  • Volar처럼 TypeScript를 자체 컴파일러와 언어 서비스에 내장하는 도구는 현재 TypeScript 6.0에 의존할 수밖에 없음
  • TypeScript 팀은 이 문제를 특정 시점의 제약으로 보고, 해당 프로젝트 유지관리자들과 협력해 TypeScript 7 지원을 확보할 계획임
  • 그 전까지는 language server plugin이 필요 없는 시나리오에서 TypeScript 7 사용을 권장함
  • Angular 프로젝트는 CLI에서 빠른 프로젝트 전체 오류 감지를 위해 TypeScript 7의 tsc를 쓰고, 편집기 지원에는 TypeScript 6.0을 함께 사용할 수 있음
  • Vue, MDX, Astro, Svelte 등은 당분간 TypeScript 6.0을 계속 사용해야 함
  • VS Code에서는 “Disable TypeScript 7 Language Server” 명령으로 TypeScript 6.0으로 되돌릴 수 있음

향후 계획

  • TypeScript 7.0 출시는 TypeScript 프로젝트에서 1년 이상 주력한 네이티브 포트의 주요 마일스톤임
  • 7.0 이후에는 새 기능 작업, 사용성 개선, 추가 성능 개선, 생태계를 위한 새 API 구현으로 돌아갈 예정임
  • TypeScript 7.0 이전과 비슷하게 3~4개월마다 새 기능 릴리스를 낼 것으로 예상함
  • TypeScript 7.1은 커뮤니티 전환을 돕기 위한 격차 해소와 새 API 제공이 예정되어 있음

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 자체 테스트 기준 TypeScript 7의 속도 향상 수치는 다음과 같음

    Codebase TypeScript 6 TypeScript 7 Speedup
    vscode 125.7s 10.6s 11.9x
    sentry 139.8s 15.7s 8.9x
    bluesky 24.3s 2.8s 8.7x
    playwright 12.8s 1.47s 8.7x
    tldraw 11.2s 1.46s 7.7x

    책임 있게 마이그레이션하면서 이 정도 성과를 낸 팀이 대단함. Bun은 좀 보고 배웠으면 함. 궁금한 건 tsdown이나 esbuild처럼 TypeScript 코드베이스를 빌드해야 하는 하위 도구에는 어떤 영향이 있는지, TS 7과 현재 tsdown을 같이 쓸 수 있는지임

    • esbuild는 TypeScript에 전혀 의존하지 않으니 문제가 없음. tsdown은 --isolatedDeclarations 사용 여부에 따라 다르고, 아니라면 블로그 안내대로 TypeScript 6을 나란히 설치하면 됨
    • Bun의 마이그레이션이 무책임했다고 보는 건지 궁금함

  • 예전엔 타입이 들이는 노력만큼 가치가 없다고 논쟁하던 시절도 있었음. TypeScript가 좋은 이유는 무엇보다 타입을 대중화했다는 데 있음

    • 타입을 싫어하는 사람은 잘 기억나지 않음. 많은 사람이 싫어했던 건 정적 타이핑, 더 정확히는 정적이고 명시적인 타이핑이었음
      예를 들어 Python은 타입이 없어서 못 쓰겠다는 식의 말도 여러 번 들었는데, 그건 말이 안 됨. Python은 강타입 언어이고, 동시에 동적 타입 언어일 뿐임.
      정말 타입이 없거나 보통 “문자열 기반 타입(stringly typed)”인 언어도 있음. 어릴 때 만졌던 AREXX는 숫자처럼 보여도 모든 값이 문자열이었고, sed 같은 Unix CLI 도구 대부분도 그렇게 볼 수 있음. 하지만 타입 관련 논쟁의 대부분은 Python 같은 동적 타입 언어를 둘러싼 것이었고, 약타입이나 무타입 언어가 대규모 프로젝트에 좋다고 말하는 사람은 거의 못 봄. 오히려 Python을 “타입이 없다”고 잘못 부르며 대규모 프로젝트에 쓸 수 없다고 하는 말을 많이 들었고, 실제로 Python으로 대규모 프로젝트를 만들던 입장에서는 혼란스러웠음
    • 예전의 타입 시스템이 그냥 별로였음. 합 타입(sum types) 같은 “OR” 타입을 표현하려고 클래스 계층을 강요하는 건 고통스러움. TypeScript, Rust, Swift, Kotlin처럼 합 타입이 있는 현대 언어들은 훨씬 쾌적함
    • 개인적으로 거의 그대로 “JavaScript에서 타이핑 오류를 겪어본 적이 없다”고 말한 사람과 세 번 대화한 적이 있음. 그중 두 명은 작업을 존중하던 사람들이라, 어떻게 그런 입장을 가질 수 있는지 이해하기 어려웠음
    • 대수적 자료형과 패턴 매칭이 판을 바꿨다고 봄. Haskell처럼 과하게 가지 않아도 타입이 갑자기 훨씬 유용해졌음
      예전 타입에 대한 노출은 C++/Java가 대부분이었고, 특히 C++는 지나치게 복잡한 언어를 만드는 법 말고는 무엇의 좋은 예시도 되기 어려움. 타입이 잘 적용된 모습을 한 번 보면 훨씬 설득하기 쉬움
    • 이제 DependentTypeScript만 기다리는 중임

  • 여기서 진짜 인상적인 건 인류가 아는 가장 진보한 타입 시스템을 위해 두 개의 별도 코드베이스를 동시에 유지한 훌륭한 팀임. Rust 재작성도 기대됨

    • Rust 재작성이 의미 있을지는 잘 모르겠음. Go는 코딩이 빠르고, 코드를 보며 TypeScript를 1:1로 다시 구현하기 쉬움
      Rust는 개발 시간이 훨씬 더 오래 걸릴 것임. Rust가 Go보다 20% 빠를 수는 있어도, TypeScript에서 Go로 얻은 향상만으로도 충분히 큼. vscode에서 Go의 11배 대신 Rust로 14배가 나올 수도 있겠지만, Go만으로도 이미 큰 차이를 만들기에 충분함
    • 가장 복잡하다고는 할 수 있어도 “가장 진보한” 타입 시스템인지는 모르겠음. 그 타이틀에 정답이 있지는 않겠지만, 증명 보조기 언어 중 하나가 더 그럴듯한 후보일 것 같음
      TypeScript의 타입 시스템을 깎아내리려는 뜻은 아니고, 실제로 매우 흥미로운 작업임
    • Hugo와 여러 주요 Go 프로젝트를 만든 Steve Francia가 에이전트 시대의 Go에 관해 쓴 글이 있음: https://spf13.com/p/go-the-agentic-language/
    • “인류가 아는 가장 진보한 타입 시스템”이 정확히 무슨 뜻인지 궁금함
    • Rust 등도 진지하게 검토한 뒤 Go를 선택한 것으로 알고 있음. 이유는 다 기억나지 않지만 원래 블로그 글에 자세히 나와 있었음

  • 몇 년 TypeScript를 쓰고 나니 Python에서 타입 주석을 직접 달고 abc 같은 기본 언어 기능을 가져와야 하는 게 정말 번거롭게 느껴짐

  • 흥미롭지만, 이제 Node가 TypeScript 타입 주석을 네이티브로 제거하므로 TSC를 거의 실행하지 않음. 큰 회귀 변경을 만들고 업데이트하지 못한 부분을 컴파일러의 정적 출력으로 확인해야 할 때 정도만 돌림
    브라우저로 갈 프런트엔드 코드도 Node의 타입 제거에 의존함

    • 맞는 말이지만, 한편으로는 에디터가 하루 종일 TypeScript 언어 서버를 돌리고 있음. 아마 CI도 그렇고, AI 에이전트도 방금 한 작업에 확신을 갖기 전에 그럴 것임

  • JSDoc 타입 문법이 계속 관심을 받는 게 반가움. 개인 프로젝트에서 TypeScript를 쓰는 가장 좋아하는 방식임. 일부 문법 변경은 업데이트가 귀찮겠지만, 대부분은 더 나아지는 방향으로 보임

  • TypeScript의 큰 고통은 프로젝트 일부에 대해 lib와 types 같은 tsconfig 설정 범위를 조정하기 어렵다는 점임
    프로젝트는 웹앱인데 vite.config.ts, Playwright, 단위 테스트 때문에 IDE 도구 쪽에 Node 타입이 들어와 있음. React 컴포넌트에 Node API를 추가해도 tsc가 불평하지 않음.
    현재 DOM 라이브러리와 Node 라이브러리를 격리하려면 프로젝트 참조 스파게티, 수많은 tsconfig.json과 tsbuildinfo 출력 파일이 필요하고, 프로젝트 참조를 쓰면서 타입 출력을 피하는 것도 번거로움

    • 정말 고통스러운 부분에 동의함. nx를 쓰고 있는데 이런 부분을 대신 처리해 줌. Playwright는 자체 tsconfig를 가진 별도 프로젝트이고, 모두 루트 tsconfig를 상속함
      단일 애플리케이션에서도 nx를 선호하고, 공유 코드는 “라이브러리”로 옮김. 빌드하지 않는 라이브러리를 쓰는데 큰 프로젝트에서는 꽤 좋음

  • 아직 TypeScript 컴파일러 API는 없지만, 작업 중이라고 하니 기대됨

    • 7.1에 들어올 예정임

  • 메모리 사용량은 줄고 성능은 크게 오른 그래프를 보면, 서버 쪽에서 TypeScript가 아니라 Go를 써야 하는 것 아닌가 싶어짐

    • 우선 서버 쪽에서 TypeScript를 실행하는 건 아님. 어떤 실행 엔진을 쓰든 변환된 코드나 JavaScript를 실행하는 것임
      그리고 요즘 선택지가 있는데도 TS/JS/Python으로 새 프로젝트를 시작하는 사람이 왜 있는지는 잘 모르겠음
    • 프런트엔드 프로젝트와 타입이나 모듈을 공유할 수 있기 때문일 수 있음. CPU 집약적이지 않은 애플리케이션에서는 거의 차이가 없기 때문일 수도 있고, 익숙하고 좋아해서일 수도 있음. 라이브러리 생태계가 엄청나게 크다는 점도 있음
    • 이건 빌드 시간 성능이지 실행 시간 성능이 아님
    • Go와 JS(Node 등)의 성능 차이가 중요한지는 용례에 따라 다름. TypeScript 컴파일러에는 확실히 중요하지만, CRUD 앱에는 전혀 중요하지 않을 수도 있음
    • 가능하다면 하나의 주 언어로 작업하는 편이 더 쉽기 때문임

  • TypeScript 팀 축하함. 길게 글이나 오디오로 올릴 내용이 있지만, 짧게 말하면 JavaScript/TypeScript 생태계는 나무로 작업하는 것과 비슷함
    싸구려 라미네이트 판지 목재, Ikea식 물건도 만들 수 있음. 코드로 치면 독창성 없는 바이브 코딩 앱일 것임.
    반대로 고급 수제 가구나 목조 고층 건물도 가능함. 어린 목재를 써서 맞춤 결합과 라미네이션 기법으로 내화성 있는 보를 만드는 식임. JavaScript/TypeScript 생태계에서도 AI를 강력한 공작기계처럼 쓰되 장인정신을 갖고 만드는 고급 결과물이 나올 수 있음. 뭔가 만들고 실행할 용기가 있다면 TypeScript/JavaScript 생태계를 받아들이면 됨

답변달기
GN⁺   [-]
Lobste.rs 의견들

  • 이유는 이해하지만, 자체 호스팅 컴파일러에서 자체 호스팅이 아닌 컴파일러로 옮긴 점이 흥미로움
    보통은 거의 항상 반대 방향으로 가기 때문에 보기 드문 흐름임

    • 이런 방향을 더 자주 봐야 한다고 생각함. 모든 언어가 컴파일러 작성에 적합한 것은 아님
      자체 호스팅은 언어가 컴파일러를 더 잘 작성하는 언어로 진화하도록 강한 압력을 주는데, 그게 항상 올바른 방향은 아닐 수 있음
    • 언어 설계자와 구현자가 자기 언어가 모든 용도에 완벽하지 않다는 걸 이해하다니, 놀라움

  • TypeScript로 코딩하지 않더라도, VSCode 자체가 TypeScript로 작성되어 있으니 이 개선이 VSCode 속도에도 영향을 주는지 궁금함
    아니면 TypeScript 언어 확장에만 영향을 주는 건지 궁금함

    • 컴파일러가 빨라지는 것이지, 마법처럼 더 빠른 코드를 만들어내는 건 아님
    • TypeScript 언어 확장에만 해당함
    • TypeScript는 JavaScript로 컴파일됨. VSCode가 실행될 때는 node.js와 Chromium이 JavaScript 코드를 실행함
      여기서 빨라지는 것은 TypeScript 코드를 받아 JavaScript로 바꾸는 컴파일러뿐이고, 이 과정은 Microsoft가 VSCode 실행 파일을 배포하기 전 빌드 파이프라인에서 일어남
      잠재적인 예외가 있다면 TypeScript LSP 서버도 빨라질 수 있다는 정도인데, 이건 실제로 실행 중에 TypeScript 코드를 파싱하기 때문임. 다만 VSCode가 TypeScript로 작성됐다는 사실과는 별개임
    • TypeScript 컴파일러는 실제로 하는 일이 많지 않음. tsc는 타입 제거 같은 최소한을 제외하고 처리 중인 코드를 건드리면 안 된다는 원칙 때문에 WONTFIX로 표시되는 것들이 꽤 있음
      그래서 TypeScript로 만든 도구들의 성능 특성은 거의 변하지 않을 것으로 예상함

  • 개인적으로 얻은 작은 팁임. 현재 맡은 프로젝트는 TS 5를 쓰지만, 예상대로 nvim에서는 그걸 쓰고 싶지 않았음
    그래서 먼저 mise로 TS 7을 설치하고, node_modules/.bin 안에 mise로 설치한 TS를 가리키는 tsgo 심볼릭 링크를 만들었음
    nvim-lspconfig가 아직도 기술 미리보기 시절의 예전 tsgo 파일명을 쓰기 때문에, nvim이 로컬 TS 대신 설치해둔 TS 7을 실행하게 됨

답변달기