MYMONDAY.ai
서비스스튜디오도구데이터·포맷73CSS 생성기19색상·이미지10인코딩·보안10웹·SEO11개발·데브옵스10파일·내보내기18계산기6가이드

Semver 버전 범위 계산기

버전과 npm 범위를 넣으면 범위에 들어가는지, 내 샘플 버전 중 어떤 것이 들어가는지, 두 버전 중 어느 쪽이 최신인지 알려 줍니다.

  • 브라우저에서 처리
  • 가입 없음
  • 무료

도구 작업 공간

범위 예제

npm SemVer 문법: ^1.2.3, ~1.2.3, >=1.0.0 <2.0.0, 1.x, 1.2.3 - 2.0.0, a || b

한 줄에 하나씩(또는 쉼표로 구분) 입력하면 위 범위에 맞는지 하나씩 검사합니다.

결과

1.9.0은(는) ^1.2.3에 포함됩니다

같은 범위를 비교 연산자로 풀어 쓰면
>=1.2.3 <2.0.0-0
비교 대상2.0.02.0.0은(는) 범위 밖에 있습니다
1.9.0이(가) 2.0.0보다 옛 버전입니다메이저 변경

1.9.0의 구성

메이저
1
마이너
9
패치
0
프리릴리스
없음
빌드
없음

샘플 버전 중 범위에 맞는 것

범위에 맞는 샘플 버전: 12개 중 4개
  • 3.0.0
  • 2.1.0
  • 2.0.0
  • 2.0.0-beta.1
  • 1.10.0가장 높은 일치 버전
  • 1.9.0
  • 1.2.4
  • 1.2.3
  • 1.2.0
  • 1.1.0
  • 1.0.0
  • 0.9.0
가장 높은 일치 버전1.10.0
가장 낮은 일치 버전1.2.3
범위가 허용하는 최저 버전1.2.3

Semver 범위 계산기는 의존성 목록을 고칠 때마다 떠오르는 질문, 즉 "이 버전이 저 범위에 들어갈까?"에 답합니다. 버전 하나, 비교할 두 번째 버전, ^1.2.0 같은 범위를 입력하면 첫 번째 버전이 두 번째보다 오래되었는지 같은지 최신인지, 그리고 범위를 만족하는지를 알려 줍니다. npm이 쓰는 semver 패키지를 그대로 사용하므로 결과가 npm install의 판단과 일치합니다.

package.json 변경을 리뷰할 때, 새 마이너 릴리스가 락파일 갱신 때 선택될지 판단할 때, 2.0.0-beta.1이 ^2.0.0에 왜 매치되지 않는지 디버깅할 때, 라이브러리의 peerDependencies 범위를 쓸 때 유용합니다.

두 버전은 MAJOR.MINOR.PATCH를 모두 갖춘 완전한 버전이어야 하며 프리릴리스와 빌드 접미사는 선택입니다. 범위는 먼저 검증하므로 잘못 입력한 범위가 오해를 부르는 "아니요"로 나오지 않고 오류로 표시됩니다. 샘플 버전 목록을 넣으면 범위가 어떤 릴리스를 받아들이는지 한눈에 보입니다. 모든 처리는 브라우저 안에서 이루어지며 서버로 전송되지 않습니다.

사용 방법

  1. 테스트할 버전 입력

    첫 번째 입력란에 1.4.2나 2.0.0-beta.1 같은 전체 버전을 넣습니다. 이 버전이 범위와 대조됩니다.

  2. 비교할 두 번째 버전 입력

    예를 들어 최신 릴리스처럼 비교 대상 버전을 넣습니다. 첫 번째 버전이 이 버전보다 오래되었는지, 같은지, 최신인지, 그리고 이 버전도 범위 안에 있는지 알려 줍니다.

  3. 범위 입력

    ^1.2.3, ~1.2.3, 1.x, >=1.0.0 <2.0.0, 1.2.3 - 2.3.4, ||로 이은 대안 같은 npm 범위를 입력하거나 예제에서 고릅니다. 잘못된 범위는 입력란 아래에 오류로 표시되고, 올바른 범위는 정규형(^1.2.3은 >=1.2.3 <2.0.0-0)으로도 보여 줍니다.

  4. 두 가지 결과 읽기

    큰 판정이 첫 번째 버전이 범위에 들어가는지 알려 주고, 관계는 두 번째 버전보다 오래됨·같음·최신과 node-semver의 diff 함수가 반환한 변경 분류를 알려 줍니다. 프리릴리스에서 정식 릴리스로 갈 때 이 분류는 직관과 다를 수 있습니다. 1.0.0-beta.1에서 1.0.0은 메이저, 1.2.3-beta.1에서 1.2.3은 패치로 표시됩니다. 두 번째 버전도 참고로 범위와 대조합니다.

  5. 경계 버전 시험

    첫 번째 버전을 경계값(상한 바로 아래 버전과 상한 바로 위 버전)으로 바꿔 보면 범위가 실제로 어디서 끝나는지 확인할 수 있습니다.

작동 원리

시맨틱 버저닝 2.0.0의 우선순위

버전은 MAJOR.MINOR.PATCH 뒤에 선택적으로 -prerelease와 +build가 붙는 형태입니다. 우선순위는 시맨틱 버저닝 2.0.0 명세(semver.org) 11항에 정의되어 있습니다. 메이저, 마이너, 패치는 숫자로 비교하므로 1.10.0이 1.9.0보다 최신입니다. 프리릴리스 태그가 붙은 버전은 같은 버전의 정식 릴리스보다 오래된 것으로 봅니다. 1.0.0-beta.1은 1.0.0보다 오래되었습니다.

프리릴리스 식별자는 하나씩 비교하며 둘 다 숫자면 숫자로, 아니면 사전순으로 비교합니다. 숫자 식별자는 항상 영숫자 식별자보다 낮으므로 1.0.0-alpha.1은 1.0.0-alpha.beta보다 오래된 버전입니다. + 뒤의 빌드 메타데이터는 비교에서 무시됩니다. 1.0.0+build.5와 1.0.0+build.9는 같은 것으로 나옵니다.

npm 범위가 풀리는 방식

범위 문법은 npm이 쓰는 node-semver 방언이며 시맨틱 버저닝 명세 자체보다 풍부합니다. 각 축약형은 비교자 한 쌍으로 풀립니다.

범위의미참고
^1.2.3>=1.2.3 <2.0.0가장 왼쪽의 0이 아닌 자릿수를 바꾸지 않는 변경을 허용
^0.2.3>=0.2.3 <0.3.0앞자리가 0이면 마이너가 메이저 역할을 함
^0.0.3>=0.0.3 <0.0.40.0.x이면 정확히 그 패치만 매치
~1.2.3>=1.2.3 <1.3.0패치 수준의 변경만 허용
1.x>=1.0.0 <2.0.0X-range 와일드카드. 1.2.x와 *도 가능
1.2.3 - 2.3.4>=1.2.3 <=2.3.4하이픈 범위. 양 끝 포함
18 || 2018.x.x 또는 20.x.x||로 대안을 연결

프리릴리스가 무시되는 것처럼 보이는 이유

기본적으로 프리릴리스 버전은 범위 안의 어떤 비교자가 같은 MAJOR.MINOR.PATCH이면서 스스로 프리릴리스 태그를 가질 때만 범위를 만족합니다. 그래서 2.0.0-beta.1은 2.0.0-alpha보다 크더라도 ^2.0.0을 만족하지 않습니다. 범위가 프리릴리스를 허용한다고 밝히지 않았기 때문입니다. 반면 >=2.0.0-alpha.0은 만족합니다. 일반 설치가 불안정한 빌드를 가져오지 않도록 하는 장치입니다.

satisfies("2.0.0-beta.1", "^2.0.0")           // false
satisfies("2.0.0-beta.1", ">=2.0.0-alpha.0")  // true

실제 예시

기본 샘플: 1.4.2는 ^1.2.0 안에 있을까?
입력
버전: 1.4.2
비교 대상: 2.0.0
범위: ^1.2.0
출력
관계: older (오래됨)
범위 만족: yes (예)

도구의 비교 함수를 직접 실행해 확인한 결과입니다. 1.4.2는 2.0.0보다 낮고 >=1.2.0 <2.0.0 안에 있습니다.

메이저가 0인 캐럿
입력
버전: 0.2.5
비교 대상: 0.3.0
범위: ^0.2.3

버전: 0.0.4
비교 대상: 0.0.5
범위: ^0.0.3
출력
0.2.5 vs ^0.2.3  ->  older, 만족: 예
0.0.4 vs ^0.0.3  ->  older, 만족: 아니요

^0.2.3은 0.3.0 직전에서 멈추고 ^0.0.3은 0.0.3만 매치합니다.

틸드의 경계
입력
버전: 1.3.0
비교 대상: 1.2.9
범위: ~1.2.3
출력
관계: newer (최신)
범위 만족: no (아니요)

버전이 1.2.9이면 범위를 만족합니다. 1.3.0이 처음으로 제외되는 버전입니다.

프리릴리스와 정식 릴리스
입력
버전: 2.0.0-beta.1
비교 대상: 2.0.0
범위: ^2.0.0
출력
관계: older (오래됨)
범위 만족: no (아니요)

범위를 >=2.0.0-alpha.0으로 바꾸면 같은 입력이 만족: 예가 됩니다.

빌드 메타데이터는 무시
입력
버전: 1.0.0+build.5
비교 대상: 1.0.0+build.9
범위: 1.0.0
출력
관계: equal (같음)
범위 만족: yes (예)

자주 하는 실수

  • 1.0.0 미만에서도 ^가 같은 뜻이라고 생각

    ^1.2.3은 모든 1.x를 허용하지만 ^0.2.3은 0.2.x만, ^0.0.3은 0.0.3만 허용합니다. 1.0 이전 패키지는 마이너 버전을 호환성 깨짐 자리로 취급합니다.

  • 프리릴리스가 일반 범위에 매치될 거라는 기대

    ^2.0.0은 2.0.0-rc.1에 매치되지 않습니다. CI에서 릴리스 후보를 테스트하려면 범위 자체가 같은 major.minor.patch의 프리릴리스를 언급해야 합니다.

  • 짧은 버전 입력

    1.2는 완전한 버전이 아니라서 1.4.0 같은 버전을 쓰라는 메시지와 함께 거부됩니다. 범위는 1.2, 1.x처럼 일부만 써도 되지만 버전은 안 됩니다.

  • 범위를 잘못 입력

    not a range나 ^1.0.0 <처럼 유효하지 않은 텍스트는 "불일치"로 처리되지 않고 범위 입력란 아래에 오류로 표시됩니다. 범위가 올바를 때의 "아니요"만 믿고, 판정 옆의 정규형으로 의도한 뜻이 맞는지 확인하세요.

  • 다른 생태계의 범위와 혼동

    Python(PEP 440), Maven, Cargo는 각자 범위 문법이 있습니다. node-semver는 ~=1.2를 ~1.2의 별칭(>=1.2.0 <1.3.0-0)으로 받아들이지만, PEP 440의 ~=1.2는 더 넓은 >=1.2, ==1.* 범위입니다. Maven의 [1.0,2.0)은 npm 범위가 아닙니다.

자주 묻는 질문

^1.2.3은 1.9.0과 매치되나요?

예. ^1.2.3은 >=1.2.3 <2.0.0을 뜻하므로 1.9.0이 만족합니다. 2.0.0이나 1.2.2는 매치되지 않습니다.

^와 ~의 차이는 무엇인가요?

^1.2.3은 마이너와 패치 업데이트(2.0.0 미만)를, ~1.2.3은 패치 업데이트만(1.3.0 미만) 허용합니다.

1.0.0-beta.1이 ^1.0.0을 만족하지 않는 이유는?

프리릴리스는 범위의 비교자가 같은 major.minor.patch의 프리릴리스를 명시할 때만 범위를 만족합니다. 포함하려면 >=1.0.0-beta.1 같은 범위를 쓰세요.

1.10.0과 1.9.0 중 어느 쪽이 최신인가요?

1.10.0입니다. semver는 각 부분을 문자열이 아니라 숫자로 비교하므로 10이 9보다 큽니다.

플러스 기호 뒤의 빌드 메타데이터도 영향을 주나요?

아니요. +build 메타데이터만 다른 버전은 우선순위에서 같은 것으로 취급됩니다.

두 번째 버전도 범위와 대조하나요?

참고용으로 합니다. 판정은 첫 번째 버전에 대한 것이고, 두 번째 버전은 첫 번째와 비교해서 오래됨, 같음, 최신을 알려 주며 범위 안인지 밖인지도 함께 표시합니다.

Python이나 Cargo의 버전 범위에도 쓸 수 있나요?

아니요. npm의 node-semver 문법을 따릅니다. 다른 생태계는 범위 규칙이 다릅니다.

더 깊이 읽기

마지막 업데이트: