[개발환경] package.json 다이어트 여정기 (depcheck, npm-check)

들어가며

개발을 진행하다 보면 어느 순간 package.json이 생각지도 못하게 길어진 것을 확인할 수 있습니다.

누군가 꾸준히 package를 관리한다면 좋겠지만 막상 그렇게 하기가 쉽지 않습니다.c

또한 길어진 package.json이 서비스상에서 큰 문제가 있는가라고 물어본다면,
번들링 툴들이 tree shaking를 통해 안 쓰는 라이브러리를 제거해주기 때문에 큰 문제가 안됩니다.

하지만 배포할때에 있어서 해당 모듈을 설치 -> 빌드하는 과정을 거치기 때문에 불필요한 모듈은 제거하는 게 좋습니다.

이번 글에서는 프로젝트에서 package.json를 다이어트하는 과정을 대한 글입니다.

다이어트 방법론

라이브러리 주인찾기

일단 라이브러리 주인 찾는 방식은 간단합니다. 해당 코드를 누가 추가했는지 확인하면 되는 부분이거든요.

vsc의 익스텐션인 GitLens를 이용하면 바로 찾을 수 있습니다. 

물론 해당 코드를 추가한다고 해서 해당 라이브러리를 무작정 사용한다고 볼순 없습니다.
merge나 refactoring 과정 중에 코드는 변경될 수 있으니깐요.

gitlens로 바로 찾은 라이브러리 설치주인들

그리고 해당 코드가 사용되는지 가장 쉬운 방법은 직접 코드로 보면 됩니다.

아래는 react-swipeable-views 라이브러리에 대한 검색 결과입니다.

해당 라이브러리의 경우 swiper 되는 뷰를 위한 라이브러리인데 해당 라이브러리 코드 주인 찾아가서 대화해보니 해당 레포가 분리되면서 해당 기능은 다 빠졌는데 package에서는 제거하지 않아 남아있는 라이브러리였습니다.

react-swipeable-views 검색화면

또한 다른 팀에서 설치한 라이브러리를 설치한 팀에서 사용하진 않지만 다른 팀에서 사용한 경우도 찾아볼 수 있었는데요.

이번에는 @nivo/bar 라이브러리였습니다. 
해당 라이브러리는 Kih으로 시작하는 동료가 라이브러리 주인인데
Kih는 사용하지 않는데, 다른 팀에서 해당 라이브러리를 사용한 경우가 있습니다.

Kih 가 설치한 라이브러리

Jaeb가 쓴 라이브러리

따라서 이렇게 일일이 주인 찾아서 물어보기엔 이미 너무도 많은 라이브러리가 설치되고 사용되고 있다는 점이 해당 방법에 대한 한계로 다가왔습니다.

또한 모든 라이브러리 리스트를 주고 해당 팀에서 사용한 이유를 가져와라 하는 것도 어려운 것이,
기능 구현이 완료되어 유지보수만 하는 중인 코드의 경우 사용한 이유를 찾는 것도 업무가 되어버리기 때문이었습니다.

그래서 다음 방법을 고민해봅니다.

라이브러리 이용하기

라이브러리에 대한 주인을 찾아서 사용한 이유를 파악하는 것은 package를 관리하는 어찌 보면 가장 좋은 방법일 수 있습니다.

단적으로 날짜 관련 라이브러리인 moment와 date-fns가 중복으로 설치되어 있었습니다. 같은 역할을 하는 모듈이 다른 팀에서 같은 목적으로 쓰고 있었습니다. 

moment와 date-fns npm trend

만약 프로젝트 초기부터 라이브러리 설치에 대한 기준과 설치된 라이브러리에 대한 전파가 적절히 이뤄졌다면 이런 식의 중복 설치는 나오지 않았을 것입니다.

위에 예시가 됐던 nivo/bar 라이브러리의 경우도 현재 프로젝트에서 차트 라이브러리는 plotly.js로 사용하고 있고 실제로 제가 해당 라이브러리를 내부에서 사용할 수 있도록 모듈화까지 해놨는데 다이렉트로 사용하고 있는 경우였습니다 ㅜㅜ

아무튼 이미 던져진 프로젝트에는 어쩔 수 없으니 이제라도 관리를 하기 위해 이번엔 depcheck 또는 npm-check이라는 라이브러리를 활용해봅시다.

depcheck이란?

how to find unused packages npm라고 검색하면 가장 상단 글에서 추천하는 라이브러리입니다.

Find unused npm packages in package.json

추천수 보고 신뢰감 566배 상승

Depcheck is a tool for analyzing the dependencies in a project to see: how each dependency is used, which dependencies are useless, and which dependencies are missing from package.json.
- depcheck 문서 발췌

쨋든 설명을 보면 프로젝트의 의존성을 확인하는데, 안 쓰는 것부터 유령 의존성까지 찾아준다고 합니다.

유령 의존성이 뭔지 궁금하다면 아래 글을 확인하세요.

[리액트] 유령 의존성부터 시작된 yarn berry 도입기

npm-check이란?

depcheck와 같은 기능을 제공하는 라이브러입니다. 다만 trend상으로는 npm-check가 덜 유명합니다.

depcheck, npm-check npm trend

아무튼 이제 이 도구를 사용해서 한번 다이어트를 해봅시다. 여기서는 depcheck를 이용하겠습니다.

모듈 다이어트 시작

다이어트에서 가장 중요한 건 before after겠죠. 그럼 before부터 가겠습니다. 대략 1기가입니다.

before

설치와 실행

npm install -g depcheck

npx depcheck

실행 화면 분석

depcheck 실행 화면

• Unused dependencies
• Unused devDependencies
• Missing dependencies

이렇게 3가지 카테고리로 나옵니다.
다만 여기서 무작정 Unused라고 지울 수가 없는 것이 devDependencies 쪽에서 나온 라이브러리 중에서 webpack, babel에서 쓰이는 라이브러리들이 무더기로 나오기 때문입니다.

따라서 제거를 하기 전에 좀 더 신중하게 접근할 필요가 있습니다.

webpack css-loader 예시

그래서 저는 리스트업 된 것들을 직접 검색해보고 그다음에 의문스러운 라이브러리의 경우 라이브러리 주인에게 물어보고 제거하기 시작했습니다.

다이어트 시작

package.json에서 삭제

고난의 연속입니다. 그리고 안타깝게도 현재 프로젝트에는 테스트 코드가 거의 없기 때문에.. 라이브러리를 함부로 지웠다가 갑자기 기능이 안된다는 비난을 받을 수 있기에 조심스럽게 제거해갑니다.

처음 보는 라이브러리의 경우 기능도 찾아보고 제거하는 것도 필요합니다.

그리고 비우기만 하면 아쉬우니깐 채우는 것도 해봅시다.

위에서 Missing dependencies에 해당하는 코드 중에 선별해서 설치합시다.

그리고 최종 결과를 확인해보면?

다이어트 결과

첫 번째로 node_modules의 크기는 대충 50MB 줄었습니다..??? 뭔가 노력 대비 손해 본 느낌인데..

용량 비교

그럼 이제 빌드 시간도 한번 살펴보겠습니다.

빌드 시간 비교

오히려 4초 정도 늘어났는데.. 이 정도는 컴퓨팅 파워 편차이니 무시해도 됩니다. 즉 변동이 없습니다.. 

그럼 나 하루 종일 뭐한 거냐,,?

마치며

위의 섹션을 통해서 알 수 있듯이 뭔가 극적인 변화를 바랐는데, 다이어트는 역시 어렵다라는 결론을 얻었습니다.

극적인 변화를 만들어내지 못한 이유에 대해 고민해보자면,

1. 50MB에 해당하는 대충 20개의 작은 라이브러리를 설치-> 배포하는 건 컴퓨터에겐 그리 큰 차이가 없다
2. 우리 팀원들은 패키지 관리를 잘하고 있다

라는 이유가 아닐까 생각합니다.

그래도 package.json에서 설치된 라이브러리 수는 30개정도 없앴다고..를 외치며 글을 마칩니다.

끝