현재 bun.lock과 구 lockb
공식 문서는 Bun1.2부터 기본 잠금 형식이 텍스트 bun.lock으로 바뀌었다고 설명합니다. 예전 바이너리 bun.lockb와 이름·형식이 다릅니다. 최신 버전을 설치했다고 모든 프로젝트의 파일이 이미 변환된 것은 아닙니다.
잠금 파일은 프로젝트의 재현 가능한 의존성 검토에 사용합니다. 파일이 있다는 사실만으로 설치가 완료됐거나 OS·네이티브 라이브러리 차이까지 모두 사라진 것은 아닙니다.
설치와 잠금만 작성
기본 bun install과 다음 명령의 범위를 구분합니다.
bun install --lockfile-only
공식 문서는 이 옵션이 node_modules에 설치하지 않고 잠금을 작성하는 경로라고 설명합니다. 하지만 전역 설치 캐시에 레지스트리 메타데이터·Git/압축 의존성을 받을 수 있습니다. 완전한 읽기 전용·오프라인 명령으로 소개하지 않습니다.
기존 잠금 파일의 선택
현재 공식 문서는 npm·Yarn·pnpm 잠금을 이전하는 경로를 안내합니다. npm-shrinkwrap.json과 package-lock.json이 함께 있으면 전자가 우선입니다. 여러 종류가 있으면 문서의 우선순위와 경고를 읽습니다.
자체 사례로 같은 가상 폴더에 npm-shrinkwrap와 package-lock이 있다고 해 보겠습니다. 내가 package-lock만 보고 예상한 버전과 실제 선택된 입력이 다를 수 있습니다. 어떤 잠금을 읽었는지와 새 bun.lock의 diff를 확인해야 합니다.
원본 보존과 검증
현재 문서는 이전 과정에서 원래 잠금 파일을 보존한다고 설명합니다. 새 파일이 생겼다는 이유만으로 곧바로 옛 파일을 삭제하지 않습니다. 의존성·스크립트·테스트와 팀/CI의 사용 도구를 확인한 뒤 유지할 관리 방식을 정합니다.
구 lockb를 텍스트로 옮기는 명령도 공식 lock 문서를 따릅니다. 버전별 옵션과 파일 쓰기 조건을 확인하고 기존 작업 사본을 보관합니다. 설치나 변환을 실험할 때 운영 프로젝트·개인 저장소를 그대로 사용하지 않습니다.
frozen·CI와 완료 기준
--frozen-lockfile 또는 bun ci는 잠금에 맞춘 설치 판단에 사용하는 경로입니다. 잠금 변경을 허용하지 않는 동작과 일반 이전을 같은 단계로 섞지 않습니다. 기존 타사 잠금을 메모리에서 해석하는 경우와 실제 새 파일을 쓰는 조건도 현재 문서에서 확인합니다.
완료 기준은 의도한 요구 조건·잠금 diff·설치·검사가 서로 맞는 상태입니다. 공식 현재 명령·이전 규칙과 자체 두 npm 잠금 사례를 대조했으며 실제 설치·캐시 쓰기·네트워크·잠금 변환·파일 삭제·CI는 실행하지 않았습니다.