Bun 1.4.3: 내장 타입 검사기 bun check, 실행 전 --check 게이트

파일 단위 --check와 프로젝트 검사의 범위 차이

문서는 tsc --noEmit && bun src/index.ts 같은 두 단계 구성을 bun --check src/index.ts 하나로 바꾸는 표를 제시한다. 검사와 실행 사이의 틈을 한 명령으로 묶은 셈이다.

다만 범위가 다르다. 인자 없는 bun check는 tsconfig.json의 files·include·exclude가 고른 파일을 보지만, 파일을 실행할 때의 --check는 그 파일과 정적으로 import되는 파일만 본다.

워커(new Worker), 이름을 계산하는 import(), TypeScript 파일 안의 require(), 코드가 띄우는 프로세스, preload로 먼저 로드되는 파일은 --check가 덮지 않는다. tsconfig.json이 이들을 포함하면 bun check가 덮는다.

package.json에 check 스크립트가 있으면 bun check는 그 스크립트를 실행하고, 내장 검사기는 bun --check로 고른다.

통과한 명령이 실제로 검사한 범위

엔트리 포인트가 통과해도 따로 띄운 워커에 타입 오류가 남아 있을 수 있다. 엔트리 검사는 쓸모 있지만 워커가 검사됐다는 증거는 아니다.

이는 속도 이전에 범위의 문제다. 소스 하위 트리, 생성된 타입 의존성, 따로 실행되는 프로세스마다 어떤 호출이 검사를 맡는지 이름을 붙여 보면 공백이 드러난다.

적합성 테스트 100%와 공개된 불일치

릴리스는 TypeScript 7.0.2 적합성 테스트 51,210개를 모두 통과했다고 밝혔다.

동시에 일부러 잘못 설정한 오픈소스 72개 프로젝트 비교에서 1건, strict를 끈 재실행에서 12건, 오프라인 퍼징에서 191건의 불일치를 공개했다.

상당한 호환 작업의 증거이지만 모든 프로그램에서 같은 진단을 보장한다는 증명은 아니다. 이 글에서는 검사기 벤치마크나 호환 테스트를 다시 돌리지 않았다.

같은 리비전에서 진단을 대조하는 명령

현실적인 시험은 기존 프로젝트 전체 CI 검사를 유지한 채 선택한 개발 명령에만 --check를 더하는 방식이다. 문서와 릴리스 노트가 제시한 명령은 아래와 같다.

bun check
bun --check src/index.ts
bun test --check
bun build --check ./src/index.ts --outdir out

릴리스 노트는 같은 프로젝트에서 tsc와 bun check 출력을 비교하는 절차도 제시했다.

bunx -p typescript@7.0.2 tsc --noEmit --pretty false > tsc.txt
bun check --no-pretty > bun.txt
diff tsc.txt bun.txt

폐기해도 되는 브랜치에 일부러 타입 오류를 넣어 명령이 멈추는지, 따로 로드되는 파일에서도 같은지 확인하는 것이 다음 단계로 보인다. 여기서 얻은 결과가 아니라 제안하는 점검이다.

check 스크립트 이름과 Bun 버전 혼재

문서는 타입 검사기가 없는 이전 Bun이 "check": "bun check" 스크립트를 만나면 끝없이 자신을 다시 실행한다고 경고한다. 팀 전체가 업그레이드하지 않았다면 스크립트 이름을 typecheck로 두라는 것이 문서의 안내다.

선언 파일 생성은 여전히 tsc의 몫이고, 에디터도 자체 TypeScript를 계속 쓴다.

--check의 가치는 선택한 실행 경로를 더 일찍 멈추게 하는 데 있고, 그 경로 밖의 커버리지는 여전히 프로젝트 전체 검사가 지킨다.