npm에서 package.json의 module version관리

최근 연습 삼아 npm모듈을 만들어서 배포하고 있었는데 그 과정에서 API가 달라지는 경우가 있었다.

혼자 사용하는 거라면 늘 그랬듯이 후딱 고쳐서 사용했겠지만, npm에 배포를 하는 모듈이다 보니 신경 써야 할 것이 있었다. 내 모듈의 API가 바뀌었는데 정작 사용하는 곳에서 수정 없이 사용한다면 오류가 날 것이기 때문이다.

 

이런 API가 변경하는 경우를 대비해서 어떻게 모듈의 버전을 잡아야 하는지, npm에서 참조하는 모듈들은 어떻게 가져다 쓰는 건지 정리해봤다. 버전 변경을 하기 전에 먼저 사용하고 있는 버전의 규칙과, package.json에서 버전을 해석하는 방법에 대해서 알아보자.

 

버전 규칙

npm에서는 {MAJOR}.{MINOR}.{PATCH}를 따르는 Semantic Versioning을 사용한다.

각 용어가 의미하는 바는 다음과 같다.
1) MAJOR: 호환성이 깨질 수 있는 API 변경
2) MINOR: 하위호환성이 유지되면서 기능 추가
3) PATCH: 하위호환성이 유지되면서 버그 수정

 

이 외에 추가로 몇 가지 알면 좋을만한 속성들이 있다.

1) 각 버전은 숫자로 nom-negative integer로 9 다음은 10이 된다.
2) pre-release라고 하여 1.0.0-alpha와 같이 -이후에 [0-9A-Za-z-]를 추가할 수 있다.
3) 1.0.0-alpha+001와 같이 +이후에 [0-9A-Za-z-]에 해당하는 metadata를 추가할 수 있다.
4) MAJOR가 0일 경우 dev단계로 언제든 API가 변경될 수 있다.

 

package.json의 버전 명시 방법

npm에서는 모듈의 의존성을 package.json에서 관리한다.

package.json에서는 Semantic Versioning에 맞게 모듈 버전을 정의하는 여러 방법이 있다.

1) 특정 버전 사용
  ㄴ MAJOR.MINOR.PATCH로 명시
2) 마지막 자리만 업데이트
  ㄴ ~MAJOR.MINOR.PATCH: PATCH만 업데이트
  ㄴ ~MAJOR.MINOR: MINOR만 업데이트
3) 호환 가능한 범위에서 업데이트
  ㄴ ^MAJOR.MINOR.PATCH: MAJOR 버전은 유지하면서 업데이트

 

npm 모듈 API변경

이제 npm에서 사용하는 버전의 개념을 이해했으니, API가 바뀐 모듈을 배포해보자.

 

만약 MAJOR버전이 1 이상이었다면 하위 호환성이 깨지기 때문에 기능 추가가 없더라도 MAJOR버전을 올려야 하는 마음 한구석 불편한 배포가 필요했을 것이다. 하지만 다행히 아직 모듈 버전은 0.x.x이다.

위의 Semantic Versioning 특징에 의해 MAJOR가 0인 경우는 API의 stable을 보장하지 않는다. 이는 ^와 충돌되는 의미를 내포하기 때문에 ^는 MAJOR가 0일때 예외적으로 동작한다는 것을 인식하고 있어야 한다.

 

다시 본론으로 돌아가면, 아직 MAJOR가 0이기 때문에 API가 바뀌는 업데이트임에도 불구하고 MINOR 버전만 올리면 되는 것이다! MAJOR가 0인 공식적으로 API가 stable하지 않은 단계에 있을 때 많은 것을 고려하고 테스트해서 Semantic Versioning에 위배되지 않도록 버전 관리에 신경을 써야겠다.