lockfile 주의점

이번 포스팅에선 패키지 매니저를 사용할 때 필수적으로 따라오는 lockfile 과 관련해 업무간 겪었던 이슈를 얘기하며 왜 lockfile 이 중요한지에 대해 얘기해보도록 하겠습니다.

 

- lockfile ?

 

대부분 Node.js 로 개발을 할 때 npm 혹은 yarn 등의 패키지 매니저를 사용하고 있을 겁니다.

각각 package-lock.json 과 yarn.lock 이라는 lockfile 이 포함되어 있는데, 개발간 팀원과의 협업 또는 배포, ci 환경에서 패키지들의

의존성에 문제가 생기지 않도록 이 파일을 이용해 의존성 트리를 관리하게 됩니다.

 

- 문제 상황

 

문제가 발생했던 패키지는 nest-winston 이었습니다.

nest-winston 은 로거용 패키지인 winston 을 Nest.js 용으로 한번 래핑한 패키지입니다.

현재 팀에서 관리하는 repo 중 2개의 repo 에서 이 패키지를 사용하고 있고, 패키지 매니저는 yarn 을 사용중이었습니다.

 

package.json

yarn.lcok

 

약 한달 전 lockfile 도 업데이트를 해줘야 하는 일이 있어서 package.json 에는 ^1.3.1, yarn.lock 에는 1.6.2 로 버전이 명시되어 있었습니다. 위의 yarn.lock 파일에 나와있듯이 1.6.2 버전에 걸려있는 디펜던시는 cli-color, fast-safe-stringify 두 패키지였고 문제가 없었습니다.

 

이슈는 약 5일전에 발생했는데요. 현재 배포시 약간의 문제가 있어 배포용 빌드를 구성할 때 yarn.lock 파일을 제거하고 있습니다.

이렇게되면 배포 과정 혹은 ASG 에 의해 새로운 인스턴스가 추가될 때 각 인스턴스에서 패키지 설치시 lockfile 이 없어 package.json 파일을 기반으로 설치 과정이 진행되죠.

 

 

문제가 발생했던 날 특별히 배포를 진행한 이력은 없었고, 오전부터 트래픽이 늘어나며 ASG 에 의해 인스턴스가 늘어나는 과정에서 새로 뜨는 인스턴스들에 위와 같은 에러가 찍히며 정상적으로 앱이 부팅되지 않고 있었습니다.

nest-winston 에 걸려있는 디펜던시는 cli-color 와 fast-safe-stringify 뿐인데 에러는 chalk 라는 패키지에서 나고 있으니, 머릿속에 물음표를 가진 채 직접 인스턴스에 들어가서 확인을 해봤습니다.

 

기존 instance

새로 뜬 instance

 

위의 두 캡쳐에서 보이는 것 처럼 실제 node_modules > nest-winston > node_modules 로 들어가보면, 원래 제대로 돌고있던 인스턴스에선 cli-color 패키지가 들어가있는데 에러가 발생하는 인스턴스에선 chalk 패키지가 들어가있었습니다.

그리고 이때 yarn.lock 파일에서 nest-winston 을 보면, 버전이 1.6.2 가 아니라 1.6.3 을 가리키고 있었습니다. (캡쳐는 아쉽게도..)

 

 

github 에서 nest-winston 패키지의 업데이트 이력을 확인해보니 그 날 1.6.3 이 publish 가 되었었는데, 이 1.6.3 버전에 cli-color 패키지가 제거되고 chalk 패키지가 추가되었습니다. 저희가 해당 repo 의 git 에서 관리중인 yarn.lock 에는 nest-winston 1.6.2 버전이 명시되어 있었지만 배포 구성간에 yarn.lock 을 지우고 있었고, package.json 파일에는 ^1.3.1 로 명시되어 있어 실제 인스턴스에는 1.6.3 버전이 설치되며 chalk 가 딸려들어오게 된 것입니다.

 

nest-winston 1.6.2

nest-winston 1.7.0

 

로컬에서 동일한 시나리오로 설치를 진행할 경우 yarn.lock 이 있을 땐 1.6.2 버전이 설치되지만 yarn.lock 을 제거하면 1.7.0 이 설치됩니다. 물론 현재 1.7.0 은 nest-winston 이 위와 같은 문제를 해결한 상태라 chalk 패키지가 빠져있습니다만, lockfile 에 따라 설치되는 의존성이 어떻게 달라지는지를 보이는 예시입니다.

 

- Conclusion

 

당시에는 nest-winston 패키지의 픽스된 버전이 업데이트 된 상태는 아니었기 때문에 package.json 파일의 버전 명시를 ^1.3.1 -> 1.6.2 로 고정해 문제를 해결했었습니다. 막연하게 lockfile 은 중요하지 라고만 생각하고 있다가 그 중요성을 다시금 상기하게 된 이슈였습니다. 애초에 왜 돌아가지도 않는 버전이 하필 패치버전이 올라가서 publish 된걸까 하는 생각도 잠깐 들긴했지만 외부 패키지를 사용하는 상황에서 이런 일은 꽤 자주 일어날 수 있는 것 같습니다. 당연히 배포 빌드 구성에서 yarn.lock 파일을 제거하는 과정이 없었다면 발생하지 않았을 문제이긴 합니다... 이건 또 다른 문제니 나중에 이 부분을 해결하게 되면 관련 글을 올려보도록 하겠습니다.