package.json의 버전 특수문자들 (~, ^, ...)

package.json의 버전 특수문자들 (~, ^, ...)

풀스택 프리랜서로 일하면서 주력이었던 C#1에서 node 관련 작업으로 전환하게 되었다. 이 과정에서 버전 관리의 중요성을 깊이 깨달았다. 특히, node의 package.json에서 버전을 지정하는 다양한 방법과 그 의미에 대해 더 자세히 알아보게 되었고, 이에 대한 나의 이해와 경험을 공유하고자 한다.

패키지 버전

노드 패키지 버전 포맷

노드는 Semantic Versioning을 사용한다. 중학교 때부터 JetBrains ReSharper를 사용해오며 Calendar Versioning에 익숙한 난 처음에 각각의 구분이 뭘 의미하는지 몰라서 대충 첫 번째가 바뀌면 엄청난 패치, 두 번째가 바뀌면 일반 패치, 세 번째가 바뀌면 소소한 패치 정도로 이해했는데 지금 보니 얼추 맞는 것 같기도 하다. 하지만 정확하지는 않다. 이는 버전 제한자, 버전 범위에서 설명하도록 하겠다.

package.json

노드는 package.json 파일로 패키지를 관리한다. 닷넷의 csproj 파일이랑 같은 역할을 한다고 봐도 무방할 것 같다. 여기에서 프로젝트 이름, 의존성 관리 등 프로젝트의 세부 사항을 관리하게 된다.

버전 제한자, 버전 범위

그리고 package.json에서는 버전 제한자를 사용하여 패키지 매니저2를 통해 의존성을 설치할 때 설치될 버전의 범위를 지정할 수 있다.

문제는 어떤 오픈소스 프로젝트는 ~를 앞에 붙이고, 어떤 건 ^를 앞에 붙이고, 어떤 건 아예 안 붙이고, 어떤 건 >, >=, <, <=를 붙이고… 마지막 부등호들은 직관적으로 이해가 되는데 문제는 ^, ~는 뭐 하는 놈인지 알 수가 없었다.

node-semver

해당 내용은 node-semver 리포지토리의 버전 섹션에서 찾을 수 있었다. 특히 자주 쓰이는 ~(틸드)와 ^(캐럿)에 대해 설명해보자면 다음과 같다.

  • 캐럿(^): 이 제한자는 메이저 버전 내에서 가장 최신의 마이너 버전으로 업데이트를 허용한다. 예를 들어, ^1.2.3은 1.2.3 이상, 2.0.0 미만의 버전을 허용한다. 즉, 메이저 버전 번호가 바뀌지 않는 한 업데이트가 가능하다는 얘기다.

  • 틸드(~): 이 제한자는 마이너 버전 내에서 가장 최신의 패치 버전으로 업데이트를 허용한다. ~1.2.3은 1.2.3 이상, 1.3.0 미만의 버전을 허용한다. 따라서 마이너 버전이 바뀌지 않는 한 업데이트가 가능하다.

>, >=, <, <= 같은 부등호들은 직관적으로 이해가 되지만, ^와 ~는 처음 보면 헷갈릴 수 있다. 이 두 제한자를 제대로 이해하고 사용하면 의존성 관리가 훨씬 수월해진다.

아무것도 지정하지 않으면 앞에 =이 붙어있는 것과 동일하게 처리된다.

주의할 점은, 버전에 >1이라 지정하면 2.0.0 이상의 버전을 의미하지만 >1.0이라 지정하면 1.0.1과 같이 1.0.0보다 큰 버전을 의미한다는 것이다. 즉 자릿수에 따라서 대상 버전 범위가 달라지므로 이를 잘 생각하고 써야 한다.

메이저 버전과 마이너 버전의 차이

소프트웨어 버전 번호는 일반적으로 메이저.마이너.패치 형태로 구성된다. 각각의 부분이 의미하는 바는 다음과 같다.

  1. 메이저 버전(Major Version): 이 숫자가 바뀌면, 그건 보통 큰 변화를 의미한다. 즉, 기존 버전과 호환되지 않는 변경이 발생했다는 거지. 예를 들어, API가 완전히 바뀌거나, 기존 기능이 제거되는 등의 주요 변경이 이루어졌을 때 메이저 버전을 올린다. 메이저 버전이 바뀌면 기존 사용자들은 업그레이드하기 전에 주의 깊게 살펴봐야 한다.

  2. 마이너 버전(Minor Version): 마이너 버전이 바뀌는 건 새로운 기능이 추가되거나 개선이 이루어졌지만, 기존 버전과의 호환성은 여전히 유지되는 경우다. 이러한 변경은 새로운 기능을 도입하거나 기존 기능을 확장할 때 발생한다. 마이너 버전 업데이트는 기존 시스템이나 의존성에 큰 영향을 주지 않으면서도 새로운 기능이나 개선을 제공한다.

  3. 패치 버전(Patch Version): 패치 버전이 바뀔 때는 보통 버그 픽스가 진행되었거나, 보안 문제가 개션되었거나, 마이너 버전을 올리기엔 뭐할 정도로 소소한 기능 개선이 이루어졌을 때이다. 즉, 전체적인 프로그램의 작동에 큰 영향을 미치지 않지만 코드가 변경되었을 때 올라간다고 보면 된다.

예시 (next.js turbopack)

다음 코드는 create-next-app --example with-turbopack으로 생성한 프로젝트의 package.json이다.

{
  "private": true,
  "scripts": {
    "dev": "next dev --turbo",
    "build": "next build",
    "start": "next start"
  },
  "dependencies": {
    "next": "latest",
    "react": "^18.2.0",
    "react-dom": "^18.2.0"
  },
  "devDependencies": {
    "@types/node": "20.8.10",
    "@types/react": "18.2.33",
    "@types/react-dom": "18.2.14",
    "typescript": "^5.2.2"
  }
}

보면 react, react-dom의 버전은 캐럿 버전으로 지정되었으므로 18.2.0 이상 19.0.0 미만의 버전 중 최신 버전이 설치될 것이다. typescript도 마찬가지로 *5.2.2 이상 6.0.0 미만**의 버전 중 최신 버전이 설치된다.

반면 @types/node를 비롯한 타입 패키지들은 prefix 없이 지정되었다. 또한 patch 버전까지 지정되어 있으므로 정확히 해당 버전만 설치되게 된다.

추가로, 만약 "@types/node": "20.8"로 지정했다면 20.8.0 이상 21.0.0 미만이 설치되게 된다.

  1. ASP.NET, WPF, WinForms, … ↩︎

  2. npm, yarn, pnpm, … ↩︎

댓글

댓글 쓰기

이 블로그의 인기 게시물

C# 남아도는 메모리에도 불구하고 OutOfMemoryException이 발생한다면?

이미지
  C# 코딩 중 평소 볼 수 없던 생소한 현상이 발생했습니다. 분명 메모리는 남아도는데(32기가바이트 중 26기가바이트 사용 가능) 프로그램이 돌다가 OutOfMemory 예외를 던지며 죽어버리는 현상이었죠. List 에 수많은 파싱된 데이터를 넣는 작업 중이었습니다.   그래서 메모리 프로파일러를 잘 관찰해보니 2GB의 메모리를 사용하면 무조건 뻗어버리는 현상을 발견했고, 왜 그럴까 생각해보다가 문득 예전 XP에서 4기가 메모리를 달아도 32비트 운영체제의 한계 아닌 한계로 3기가 조금 넘게밖에 인식을 못 했던 것이 생각났습니다. 생각은 자연스럽게 컴파일이 32비트로 됐구나! 쪽으로 넘어갔고 프로젝트 설정에 보니 빌드 항목에 해당되는 체크박스가 있더군요.   현재 메모리가 남아도는데도 OutOfMemory 예외가 뜬다면 100% 저게 체크된 상태일 겁니다. 그림과 같이 체크 해제 하신 후 실행하시면 특별한 경우가 아닌 이상 컴퓨터 메모리가 바닥날 때까지 저 예외를 볼 일 없게 될겁니다.
자세한 내용 보기

USB를 뒤는 괜찮은데 앞에 꽂으면 인식이 힘들다?

이미지
USB 장치 인식 실패   보기만 해도 짜증나는 제목이죠. USB 장치 인식 실패. 원인은 여러가지가 있을 수 있습니다. USB 컨트롤러가 고장이거나, USB 케이블이 단선됐거나, 전원 공급이 원활하지 않거나. 하지만 뒷쪽에 꽂으면 괜찮은데 앞에 꽂으면 USB 장치 인식을 실패한다면? 십중팔구 전원 문제입니다. 불안정한 전원 공급   본체 앞쪽에 달려 있는 USB 포트는 메인보드에 다이렉트로 붙어 있는 뒷쪽과 달리 메인보드에서 케이블 하나를 거쳐 전면 패널에 연결 됩니다. 게다가, 이 케이블과 연결되는 메인보드의 부분은 주로 메인보드에 전원이 연결되는 부분과 정 반대쪽에 있기 때문에 , 저가형 불량 메인보드에선 아예 회로 자체가 잘못돼 전원이 제대로 전달되지 않는 경우도 있습니다.   이렇게 메인보드 자체의 문제일 경우엔 어쩔 수 없지만, 그게 아니라면 몇 가지 시도해 볼 수 있는 방법이 있습니다. USB 포트 청소   전원 공급이 불안정한 이유 중 하나가 될 수 있는 포트 내부의 먼지. 접촉 단자 사이에 먼지가 끼어 전류를 방해하거나 합선시키기도 합니다. 우선 USB 포트를 청소해주세요. 오래된 USB 케이블 교체   USB 케이블이 오래된 경우, 접촉면이 휘거나 벌어져 제대로 꽉 맞물리지 않거나, 싸구려라면 심할 경우 접히고 접히다 단선된 상태일 수도 있습니다. 오래된 USB 케이블은 교체해주세요. 메인보드의 USB 선 연결 상태 확인   메인보드를 보면, 파워가 연결되는 부분과 정 반대쪽(주로 맨 아래쪽)에 위와 같이 생긴 USB 커넥터가 연결돼 있을 겁니다. 못 찾겠으면, 본체 전면 패널쪽에서 이어져 오는 선중에 위와 같이 생긴걸 찾아보세요. 저걸 빼서 대충 후후 불고 다시 꽂아주시기 바랍니다. 항상 꽂혀 있는 것이라 정성스레 청소할 필욘 없어요. 단, 저 케이블 어딘가가 접혀있다면 꼭 펴주세요. USB 절전 모드 사용 안 함   위 영상을 보시고 똑같이 따라해주세요. 일부 파워 용량
자세한 내용 보기

MySQL 데이터 타입과 Java 데이터 타입 비교/매칭

  안녕하세요? 혼살입니다. 블로그에 정말 오랜만에 글을 씁니다. 일하고 겜하고 일하고 겜하고 집에 박혀서 매일 똑같은 일상을 보내다 보니 블로그에 글을 오랫동안 안 쓰고 있었네요. 대부분 근황은 유튜브 동영상으로 대체하다 보니 더욱 더 그랬던 것 같습니다.   하지만 이번엔 영상보다 글로 남기는 게 더 유익할 것 같아 간만에 글을 쓰게 되었습니다. 바로 MySQL Data Types & Java Data Types 매칭! 현재 진행중인 외주 작업 중 SET 타입을 Java에선 어떻게 처리하나 찾아보다가 잘 정리된 블로그 글 을 발견해 나중에 손쉽게 찾기 위해 제 블로그에도 씁니다. 위 링크에 들어가시면 테이블로 잘 정리돼 있으니 한 번 들어가 보시는것도 괜찮겠네요. 왼쪽은 MySQL, 오른쪽은 Java의 데이터 타입입니다. BIT <-> Boolean TINYINT <-> Integer BOOL/BOOLEAN (TINYINT(1)) <-> Integer SMALLINT <-> Unsigned 상관없이 Integer MEDIUMINT <-> Integer, Unsinged라면 Long INT <-> Integer, Unsigned라면 Long BIGINT <-> Long, Unsigned라면 java.math.BigInteger FLOAT <-> Float DOUBLE <-> Double DECIMAL <-> java.math.BigDecimal DATE <-> java.sql.Date DATETIME <-> java.sql.Timestamp TIMESTAMP <-> java.sql.Timestamp TIME <-> java.sql.Timestamp YEAR <-> yearsIsDateType이 설정됐다면 java.sql.Date, 아니라면 Short CHA
자세한 내용 보기