Git & Github

[Git] npm package-lock.json conflict (충돌해결 및 존재이유)

heeney 2022. 2. 19. 16:13
728x90

 

[Git] npm package-lock.json conflict (충돌해결 및 존재이유)

 

 

package-lock.json 파일을 아시나요?

package.json은 봤어도 package-lock.json은 생소한 사람도 있을 것이다. 프로젝트를 하다가 만나본 적은 있어도 정확히 저 녀석이 하는 일이 무엇인지 잘 몰랐다.
'package'라는 단어가 들어갔으니 중요한 녀석인 것 같고 삭제하면 안될 것만 같다. 구글링을 해보니 작업한 파일과 함께 커밋해야한다고 한다. 바쁘니 일단 넘어가자고 생각했다. 그렇게 어물쩡 넘어가고 "해치웠나?" 라고 생각하면 나중에 뒷통수를 얼얼하게 얻어맞는다.
고맙게도(?) 뭔지 모르는데 그냥 적당히 넘어가면 내가 확실히 알게 될때까지 세상은 알아야만 하는 상황을 제공해준다.

 

 

어쩌다.. 충돌이 난건데? 💥

처음에 프로젝트 파일을 clone한 뒤, npm install을 하고, 내가 작업을 하다보면 package-lock.json이라는 파일이 새로 생성된다.
뭔가 내용이 많다.

어쩌구 저쩌구

dependencies도 있고 뭔가 되게 많이 있다. 내가 뭘 어떻게 한게 아니라 npm install을 하면 해당 파일이 생성된다.
작업 내용을 커밋 후 rebase를 하면 충돌이 짠- 하고 난다.

 

야 잠만

이야 rebase를 했는데 뭔가 많이 바뀌었다고 알려준다. Incoming할지, current할지 선택하라고 하지만 그게 진짜 1억개쯤 된다고 생각하면 된다. 놀란 가슴을 부여잡고 해결방법을 찾느라 충돌난 내용을 캡쳐해서 올리지 못한게 아쉽지만 아무튼 정신적 충격을 주기에는 모자람이 없었다.

 

 

충돌의 이유

package.json을 직접 수정하게 되면 서로 동기화되지 않기 때문에 발생한다. 나는 eslint의 버전을 강제로 낮추었기 때문에 발생한 문제라고 추측하고 있다.
또한 내가 clone하기 전에 package-lock.json 파일이 해당 프로젝트 폴더에 push되어 있지 않았을 수도 있다.

 

 

걍 지우면 안됨?

이런 생각 하는 사람 많을 것 같은데 일단 나부터 그렇다. 충돌나서 고민하다가 그냥 지웠다. 그리고 화를 입게 되는데...
예측가능한 방식으로 디펜던시를 관리하려는게 package-lock.json의 존재 이유인데 이렇게 되면 패키지의 디펜던시 트리의 많은 부분을 의도치 않게 바꿔버릴 수 있다.

 

+ eslint 버전에 대한 충돌, 재설치해도 안되었던 이유는 'package-lock.json'을 강제로 삭제했기 때문이다.

eslint가 프로젝트 내에서의 버전과 내 버전이 맞지 않았는지 충돌이 나서 node-modules를 삭제하고 다시 install했지만 해당 방법도 안되었다. 결국 강제로 local에서 사용하는 eslint의 버전을 내려서 사용하기도 했다. 버전을 낮춰서 쓰는게 맞을까? 라는 생각이 들어서 결국 다시 파헤쳐 찾아보다가 모든 내용(eslint, prettier)을 재설치하니 해결되었다. 원래 처음에 시도해보았던 방법대로 node-modules를 재설치하면 되는게 맞는데 아마 전에 설치된 내용들이 남아있어서 계속 해결이 안되었던 것 같다. 깔끔하게 지우고 다시 설치하니 해결이 되었다.

재설치를 시도해볼 시점에 내가 package-lock.json 파일의 충돌 때문에 강제로 삭제를 했는데 이 때문에 문제가 발생했다고 추측한다.

 

 

그럼 package-lock.json이 뭔데? 왜 있어야 해? 📦

우선 package.json에는 해당 프로젝트에서 의존하고 있는 모든 패키지의 이름과 버전이 담겨있고 npm install을 통해 이 모든 패키지들을 설치할 수 있다.

그런데 팀원들이 협업을 하는 과정에서 package.json을 통해 npm install을 해도 시간과 장소에 따라서 서로 다른 버전의 패키지가 설치될 수 있다.
package.json에는 version range를 사용해서 명확한 버전 정보가 아닌 버전의 범위를 담고 있기 때문에 어떤 사람은 업데이트된 패키지를 설치할 수도 있기 때문이다.
그렇게 되면 팀원들 간에 패키지 버전이 달라서 몇몇 기능이 정상 작동할 수 없는 문제가 발생한다.
이러한 혼선을 막을 수 있는 파일이 package-lock.json이다.

패키지가 최초로 추가될 당시 정확히 어떤 버전이 설치가 되었는지 package-lock.json에 기록된다. 파일 안에는 의존성 트리에 대한 정보를 모두 가지고 있다.
그러면 package-lock.json을 통해 정확한 버전명을 install하게 하고 협업 시에 충돌을 방지할 수 있다.

기존 및 신규 패키지가 추가되거나 수정될 경우 자동으로 package.json과 package-lock.json이 동기되기 때문에 수정하거나 건드릴 필요가 없다.

 

결론

협업할 때 버전이 달라서 생길 수 있는 문제를 명확한 버전을 명시해둠으로 미리 해결하도록 돕는다.
해당 파일이 git에 있어야 명확한 버전을 팀원들이 모두 동일하게 install할 수 있다.

 

 

그래서 어떻게 해결했나? ✂️

정답부터 말하자면, npm ci

npm ci

 

특징

  • 협업을 하고 있거나 같은 개발 환경을 구축해야하는 상황에 사용하면 된다.
  • 속도가 npm install보다 빠르다.
  • npm install 과 달리 package-lock.json 파일을 변경하지 않는다.
  • node-modules를 제거하고 package-lock.json을 기준으로 다시 재설치한다.

 

node-modules를 재설치하도록 돕고 package-lock.json을 변경하지 않아서 이 방법으로 해결이 가능했던 것 같다.
일단 '~것 같다'라는 건 확실하지 않아서 하는 말이 맞다. 추측할 뿐 좀 더 깊이 공부가 필요할 것 같다.

 

 

느낀 점

  1. (올바른 방법으로 검색하고 있다는 가정하에) 구글링할 때 도저히 답을 찾지 못했을때는 꼭 영어로 검색하고 영어로 된 글들을 읽자. 무조건 답이 있다.
  2. 블로커는 언제나 개발자에게 성장을 촉진한다.
  3. 자주 하는 것은 잘하게 된다. 작고 하찮은 문제 해결이라도 문제 해결의 경험이 쌓이기 때문에 문제를 빠르게 잘 해결하게 된다.
    점점 문제에 봉착해도 두려워지지 않게 되고 비슷한 패턴의 문제를 자주 만나기 때문에 빠른 시간 내에 해결할 가능성이 높다.

 

 

참고

package-lock.json 파일 충돌 해결 방법

 

Solving conflicts in package-lock.json

Why you should never delete package-lock.json and how npm can solve the conflicts for you

tkdodo.eu

package-lock.json

 

패키지 잠금 파일 (package-lock.json, yarn.lock)

Engineering Blog by Dale Seo

www.daleseo.com

npm install VS npm ci

 

GitHub - TEAM-ARK/inflearn-clone-front: 인프런 웹앱을 만들어보는 팀프로젝트

인프런 웹앱을 만들어보는 팀프로젝트. Contribute to TEAM-ARK/inflearn-clone-front development by creating an account on GitHub.

github.com

 

 

 

728x90