npm module

지금 제가 맡고 있는 프로젝트들은 같은 어드민 성향을 띄지만 서로 사용자들의 성격이 다릅니다.
기획에서 요구하는 데이터나 날짜, 시간과 관련된 포맷팅이 비슷하여 비슷한 유틸함수들이 여러개 생기게 되었습니다.
각각의 프로젝트에서 다른 이름이지만 같은 동작을 하는 함수들이 하나 둘 쌓였고 관리 포인트를 줄이기 위해 라이브러리 제작을 하기로 했습니다.

이 라이브러리에 컨셉은 경량화와 유연함이었습니다.
라이브러리의 크기는 작지만 우리가 관리하는 프로덕트에 여기저기에 쓰여야 했으니까요.
기본적으로 확장성과 재사용성을 고려했고 class를 활용하여 기능에 따라 함수들을 분리하기로 했습니다.
코드의 안정성을 위해 테스트 코드도 도입하기로 했습니다.

어떤걸 넣어야할까?
기존 프로젝트에서 helpers와 function 폴더를 통채로 꺼내와서 살펴보았습니다.
일단 프레임워크를 사용하는건 제외하고 나머지 함수들을 기능별로 분류했습니다.
크게 button, chart, date 등 9가지로 나눌수 있었습니다.
독립적인 함수들은 class의 static method로 만들었고 재사용이 필요하거나 멤버 변수를 활용해야 될 경우 new연산자로 instance를 생성해 관리할수 있도록 했습니다.

기능들의 안정성을 위해 jest로 테스트 코드를 작성하기로 했고 테스트커버리지는 95% 이상 유지할 수 있도록 구성하였습니다.

테스트코드까지 작성하고 npm 패키지를 배포하는 방법에 대해 알아본 후 진입지점을 만들었습니다(index.ts).
가지고 있는 class에 직접 접근이 가능하게 하기위해 build 작업 없이 배포하게 되었습니다.

그렇게 라이브러리는 세상에 나오게 되었습니다.

하지만 한 번에 잘되면 재미없어서 일까요?
배포하고 적용하자마자 예상치 못한 문제가 생겼습니다.
라이브러리 만들때 사용했던 의존성의 버전들과 적용하려는 프로젝트의 의존성 버전들이 달라 충돌이 생겼습니다.
peerDependencies를 사용하여 의존성들의 버전을 명시하여 충돌을 막았습니다.

처음에는 번들링 하지 않고 배포하여 사용할 때 간편함이 있었지만 라이브러리가 경량화 되어야 된다는 목소리들이 나왔습니다.

webpack으로 번들링을 하였고 170kb이던 라이브러리는 148kb(-12.94%)로 크기를 줄여 배포되었습니다.

 

이 과정에서 라이브러리를 만들고 배포하고 관리하는 것에 대한 한 사이클을 경험할 수 있게 되었습니다.

항상 개발을 하며 라이브러리를 사용하고 있지만 이 부분에 대해 깊게 고민해본 적이 없었는데 그런 시간이 될 수 있어 뜻깊었습니다.

이번에는 webpack으로 번들링했지만 번들링하는 라이브러리 중 rollup이 좀 더 간편하고 작은 모듈을 만들 수 있다고 해 도전할 예정입니다.