node_modules도 git에서도 관리하면 어떨까?

Introduction
장점
큰 diff는 개발자가 관리할 수 있다.
결론

Introduction

우리가 node_modules 폴더를 버전관리 시스템에 두지 않는 이유는 많다.

node_modules는 내(우리)가 직접 작성한 코드가 아니다.
node_modules는 매우 큰 폴더고, git diff와 pull requests를 성가시게 만든다
node_modules내 코드는 npm을 통해 쉽게 복제해 갈 수 있다.

그러나 만약에 node_modules를 버전 관리 시스템에서 관리해야 한다는 사람이 나타나면 어떻게 받아드려야 할까? 위 세가지 이유 때문에 정말 관리할 폴더가 없는 것일까? 만약 관리하기 시작한다면 어떻게 될까?

장점

장점1. 설치가 불필요해진다.

node_modules가 버전 관리 시스템에 들어가면 이제 더이상 설치할 필요가 없어진다. 이는 비단 개발자에게만 도움이 되는 것이 나리나, CI에서 돌아가고 있는 모든 봇 (CircleCI, Github Action 등..)에도 큰 도움이 된다. npm install 이던 npm ci이던 이던 어느정도 시간이 걸리는 작업이다. 그리고 이 작업은 봇에서 더 오래 걸릴 수 있다. 모든 PR과 배포에 대해 이 작업이 수행된다고 상상해보면, 상당히 많은 설치 작업이 반복적으로 일어나고 있을 것이다. 이를 버전 관리 시스템 안으로 집어 넣으면, 많은 시간과 대역폭을 절약할 수 있게 될 것이다.

장점2. 완전히 복제된 빌드 보장

node_modules가 버전 관리 시스템에 들어가면 완벽하게 개발자간에 동일한 dependencies를 가지고 동일한 코드를 실행한다는 것을 보장할 수 있다. 물론 package-lock.json과 기타 여러가지 도구를 사용하여 이러한 동일성을 보장받을 수도 있지만, npm ci 라도 설치전에 node_modules를 삭제하기 때문에 패키지 상황에 따라서 변화가 있을 여지가 존재한다.

If a node_modules is already present, it will be automatically removed before npm ci begins its install.

따라서 node_modules를 버전 관리 시스템에 넣는 것 만큼 완벽하지는 않을 것이다.

장점3. 배포되고 있는 코드에 대한 경각심

node_modules가 버전 관리 시스템에 들어가면 이 의존성이 변화할 때마다, PR에서 엄청난 Diff를 보여줄 것이다. 물론, package-lock.json도 있지만, 이 파일은 기본적으로 diff가 생략되어 있기 때문에 종종 무시되고는 한다. PR에서 볼 수 있는 node_modules의 변화가, 디스크의 파일 크기에 관심을 갖게 하거나, 의존성이 미치는 영향 등을 다시금 살펴보게 되는 계기가 될 것이다.

장점4. 의존성 추가에 대한 가치있는 고민

앞서 언급했던 것처럼, git diff를 소음이라고 볼 수도 있지만, 이를 다시 생각해보면 우리가 배포하고 있는 코드에 대한 유용한 소음으로도 볼 수 있을 것이다. 종종 내가 직접 몇줄의 코드를 추가하고 싶지 않아서 라이브러리 의존성을 한줄 추가하는 경우가 있다. (lodash라던가, underscore라던가...) 하지만 git diff를 보게되면, 내가 추가하려는 의존성이 정말로 가치있는 일인지 한번 되돌아 볼수 있는 기회가 될 것이다.

예를 들어, lodash를 설치한다고 가정해보자. 버전관리 시스템에 node_modules가 없다면 그냥 package.json에 한줄, 그리고 diff가 생략되어 있는 package-lock.json에 몇줄 추가 되겠지만, 버전관리 시스템에 node_modules가 들어간다면, lodash에서 제공하는 온갖 유틸들이 다 설치되는 것을 보게 될 것이다. 이는 개발자들에게 경각심을 줄 수 있다. 내가 진짜 lodash가 필요해서 쓰는 건지를 말이다.

장점5. left-pad 사건을 방지할 수도 있다.

left-pad 사건을 아는가? 요약하자면, 온갖 패키지에서 쓰고 있던 left-pad라는 npm 패키지를 (고작 11줄 밖에 되지 않았다) 강제로 삭제해버리자, 이를 의존성으로 사용하고 있던 온갖 패키지에서 에러가 난 사건이다.

그렇게 엄청난 것도 아닌,, 11줄 짜리 코드

물론 장기적으로는, 이렇게 갑자기 날라간 패키지에 대한 대처를 해야겠지만, 단기적으로는 패키지 삭제와 관련 없이, 우리의 소스와 배포는 무사할 것이다.

큰 diff는 개발자가 관리할 수 있다.

node_modules가 버전 관리 시스템에 들어간 상황에서, 만약 새로운 의존성이 추가된다면 diff가 많이 생겨나는 것은 자명한 사실이다. 예를 들어 타입스크립트 하나만 업데이트 해도, git diff는 엄청나게 거대해질 것이고, CHANGELOG를 일일이 뒤지며 이것이 무엇이 바꼈는지 일일이 확인하는 것은 별로 가치 있는 일은 아니다. 이러한 잡음을 최소화 하기 위해, node_modules를 수정하는 PR이 있다면 node_modules외에 다른 파일은 PR에 올리지 않게 한다면 어떨까? 개발자는 새로운 혹은 수정된 의존성을 확인하는 작업과 진짜 코드를 수정하는 작업을 분리할 수 있으므로 도움이 될 것이다.

물론, 의존성 업데이트로 인해 우리의 코드를 업데이트해야 할 수도 있다. (typescript 버전 업과 같이) 이 경우에는 이러한 규칙을 임시로 무시하면 된다.

결론

만약 내가 새로운 코드를 작성하거나, 스타트업에서 일할 기회가 생긴다면 😏 node_modules를 버전관리 시스템에 넣는 것을 한번 추진해볼 것 같다. 물론 익숙해지려면 시간이 걸리겠지만, 관리로 인한 소음 보다 개발자에게 가져다 줄 수 있는 이익이 클 것 같다.

Table of Contents