배경
회사에서 메인 작업을 진행하던중 기존 DesignSystem(DS)에 존재하던 컴포넌트의 결함 및 DS 컴포넌트를 신규로 제작하는 과업이 생겼어요.
DS 컴포넌트가 메인 작업에서 필요했었기때문에 작업방향은 크게 2가지로 나뉠 수 있었어요.
1️⃣ 메인작업에 쓰일 컴포넌트는 로컬 컴포넌트로 제작하고 추후에 DS에 작업해서 배포하기
2️⃣ DS 컴포넌트를 우선적으로 제작하고 함께 배포하기
저는 로컬컴포넌트로 제작 후 추후 DS로 옮기는것은 비효율적이라고 판단했고, 코드리뷰에서 시간이 조금 걸리더라도 DS 작업을 병렬적으로 가져가는것이 좋다고 판단했어요.
문제지점
위와 같이 의사결정을 한 후, DS 작업을 통해 기존 컴포넌트의 결함 수정 및 새로운 컴포넌트 제작을 진행하였어요.
그러나 작업한 내용을 테스트할 방법이 마땅치 않았어요.
기존에 존재하던 테스트방법은 storybook으로 확인하거나 npm 패키지 배포를 통해 확인하는 방법뿐이였어요.
하지만 발견된 결함은 제품에 결합되었을때 생기는 결함이였기때문에 storybook에서 완벽히 재현할 수 있음을 보장할 수 없었어요.
그래서 로컬에서 테스트해볼 수 있는 방법이 없을까? 하면서 질문을 했더니 yalc라는 라이브러리를 알게되었어요.
yalc란?
yalc는 로컬에서 개발 중인 npm 패키지를 테스트할 때 사용하는 도구로, 패키지를 실제로 npm에 배포하지 않고도 다른 프로젝트에서 설치해서 확인할 수 있게 해줘요.
보통 NPM 패키지를 개발할 때, 아래와 같은 과정을 거치는데요
1️⃣ 패키지 작성 (개발)
2️⃣ NPM에 배포 (npm publish)
3️⃣ 다른 프로젝트에 설치 (npm install)
4️⃣ 테스트 후, 문제가 있으면 다시 수정 후 재배포
하지만, 이 방식은 배포 과정이 필수라서 수정사항이 생길 때마다 NPM에 업로드해야 하는 번거로움이 있어요.
yalc의 경우에는
1️⃣ 로컬 패키지 개발용이성
2️⃣ 변경사항 즉시 적용
3️⃣ NPM보다 간편한 워크플로우
와 같은 차이점이 있기때문에 더 선호되는것같아요.
또한, 기존의 npm link처럼 심볼릭 링크 방식으로 동작하지 않고, ~/.yalc 폴더에 패키지를 패키징한 후 대상 레포지토리에 실제 파일 형태로 저장하기 때문에, node_modules까지 심볼릭 링크를 생성하는 npm link와는 달리 의존성 충돌이나 예기치 않은 문제를 일으키지 않아요.
즉, yalc는 패키지를 일종의 로컬 레지스트리처럼 다루기 때문에 더 안정적이고 예측 가능하게 작동해요.
적용방법
yalc는 CLI 커맨드를 통해서 손쉽게 붙일 수 있어요.
설치
글로벌 또는 프로젝트 내부에 설치
$ npm install -g yalc
패키지 버전 변경
yalc가 패키징할 패키지의 버전을 테스트용 버전으로 변경해주세요.
변경된 버전은 추후 설치할 로컬 패키지의 버전이 되어요.
// package.json
{
"name": "some-package",
"version": "3.1.5-yalc-test",
...
}
패키징
먼저 패키지를 빌드하고 이후 yalc를 통해 패키징 해주세요.
$ npm run build
$ yalc publish {패키지이름}
# e.g. yalc publish @some-package@3.1.5-yalc-test
패키지 설치
테스트할 프로젝트에서 패키지를 추가해주세요
$ yalc add {패키지이름}
# e.g. yalc add @some-package@3.1.5-yalc-test
잘 설치된 모습
패키지 업데이트
패키지를 수정하고 다시 배포하려면 아래처럼 해주시면 돼요
push를 활용하면 yalc update 하고 yalc publish를 한번에 트리거 할 수 있어요.
$ yalc push {패키지이름}
# e.g. yalc push @some-package@3.1.5-yalc-test
패키지 제거
테스트가 끝났다면 패키지를 제거해야 해요.
제거하지 않으면 추후 실제 배포용 패키지와 충돌이 있을 수 있어요!
$ yalc remove {패키지이름}
# e.g. yalc remove @some-package@3.1.5-yalc-test
마무리
yalc를 활용해서 성공적으로 서비스에 테스트하고 적용할 수 있었어요 ☺️
기존의 npm 패키지 테스트 방식이 비효율적이라고 느껴 더 나은 방법을 찾던 중 알게 된 도구인데, Design System뿐만 아니라 다양한 패키지에도 활용할 수 있어 공유 가치가 높다고 생각했어요. 이 도구를 통해 사내 Frontend 챕터에 공유할 수 있었고, DS 온보딩 문서에도 기여할 수 있어 의미 있는 경험이었어요.
온보딩 문서 기여 성공
