githru/githru-boot

package-lock.json의 gitignore 처리에 관하여

Closed this issue · 0 comments

ytaek commented

Full context는
#2 를 참고해주세요~.

네 좋은 의견 주셨네요.
package-lock.json은 말씀처럼 version명시 및 디펜던시 트리 구조를 확인하기 위해서도 gitignore 처리하지 않는 것이 맞습니다.
사실 이부분은 특정 상황을 제외하고 명확하게 결정이 난 부분이 있습니다. 하단의 레포가 package-lock.json에 대한 부분이 없거든요.

다만 현재 레포가 모노레포가 아니지만 :id로 구분지어지는 폴더 하위에서 각각 실행이 되어야 하는 구조기 때문에 루트에서 :id폴더 하위에 노드 모듈을 사용하기 위해서 npm install을 할 일이 없다고 판단했습니다.
이에 더해서 짧은 package.json 대비 긴 package-lock.json이 diff에 남는게 부담스럽기도 했네요.

그러나 버전 픽스의 경우는 말씀처럼 package-lock.json을 포함시키지 않는 것으로 유지가 가능하지만 핀트가 어긋난 것으로 보입니다.
Tilde와 Caret Ranges를 잘 사용하는게 정답으로 보입니다.

또한 package-lock.json을 포함시키지 않더라도 CI는 clean and install, npm ci를 사용하는 파이프라인이 일반적이라..

package-lock.json을 클리어하고 npm install하는 경우는 CI 환경과의 간극이 계속 커져버리는 상황에는 자유로울 수 없습니다.
그 반대로 package-lock.json을 계속 유지한 상태의 npm ci하는 경우는 write권한이 없기 때문에 같은 환경을 유지 할 수 있습니다.

npm ci를 하는 것으로 기대할 수 있는 장점은 다음과 같은 것들이 있는데요,

  1. npm ci 가 더 빠르다.
  2. (package-lock.json 파일을 지속적으로 버전 업데이트 한다면) CI입장에서는 npm ci를 사용하는 것으로 npm install을 사용했을 때 발생하는 package.json과 package-lock.json의 동기화 행위에서 발생할 수 있는 문제에 대해서 자유롭고 모듈상위 버전이 상위 호환성을 제공한다는 SemVer 규약을 신뢰한다는 기정 하에 같은 기능이 성능적으로 개선된 모듈을 사용할 수 있다.

2의 경우는 npm의 이상적인 목표인데 사실 그렇지 않다는 걸 많은 분들이 경험해 봤을 것 같네요.
최근에도 단편적으로 http-errors가 버전 2점대로 올라가면서 express와 충돌을 일으킨 경우도 있으니까요.

그렇다 하더라도 개인적으로는 언제나 2의 순기능을 믿고 있습니다. 😄

Originally posted by @ansrlm in #2 (comment)