네이티브 TS, Binary Lockfile, Drop-in 대체

세 Bun 개념이 진짜 사용에서 반복적으로 surface; 이해하면 대부분 놀람 방지.

네이티브 TypeScript. Bun 이 .ts 와 .tsx 파일 직접 실행. tsc 컴파일 단계 없음, 시작에 tsconfig.json 안 필요. 후드 아래선 Bun 이 런타임에 type annotation 제거 — 타입 erase, JS 실행. 빠른데 의미하는 게 Bun 이 type-check 안 함. type 에러 있으면 Bun 이 안 잡음; 여전히 CI 에서 bunx tsc --noEmit 필요.

Binary lockfile (bun.lock). 옛 Bun 버전이 bun.lockb 사용 (순수 binary); 현재 버전이 bun.lock 사용 (텍스트 기반, 그치만 여전히 파싱 속도 최적화된 Structure-of-Arrays 형식). 어쨌든 파일 형식이 의도적으로 JSON 기반 lockfile 보다 빠르게 파싱. 항상 commit.

Drop-in npm 대체. Bun 이 같은 package.json 읽음, 같은 npm registry 와 talk, 같은 node_modules 채움. Node.js 패키지에게 Bun 이 Node.js v24.3.0 처럼 보임 (호환성 위해 버전 spoof). 대부분 패키지 '그냥 작동'. 예외: native addon (Node 의 V8 internal 에 의존하는 컴파일된 C++ — 가끔 깨짐), 일부 niche Node 전용 API (모든 release 마다 개선), 매우 tight Node 버전 체크 가진 패키지.

Code

Bun 의 TypeScript 처리 검증·bash

# bun 이 TS 직접 실행
echo 'const x: number = 42; console.log(x);' > demo.ts
bun demo.ts
# 42

# 그치만 Bun 이 type-check 안 함 — 이게 통과:
echo 'const x: number = "this is a string"; console.log(x);' > broken.ts
bun broken.ts
# this is a string  ← 어쨌든 돔, 타입이 런타임에 제거됨

# CI 가 type 체크 위해 tsc 따로 돌려야 함
bunx tsc --noEmit

Exercise

쓰는 npm 패키지 하나 골라서 https://bun.sh/docs/runtime/nodejs-apis 에 호환 listed 됐는지 체크. 시간 있으면 작은 Node 스크립트를 'bun script.js' 로 port 해서 어떻게 되는지 봐. 호환성 스토리가 대부분 '그냥 작동' 인데 mission-critical 한 건 확인 가치 있어.

네이티브 TS, Binary Lockfile, Drop-in 대체

Code

External links

Exercise

Progress

댓글 0