[Road To Contribute] 1. Zustand를 fork한 후 첫 테스트를 실행해보자

여러분들은 개발자가 되고 싶은 이유가 있으신가요 ?

 

처음 React를 접하며 프론트엔드 개발을 시작할 당시 저는 GitHub라는 방대한 오픈소스 커뮤니티가 가지는 매력에 사로잡혔습니다. 분명 '코드'는 나의 자산이기때문에 Private하게 보관하고 남들에겐 숨길줄 알았지만 GitHub에는 자신의 코드를, 나아가 기업의 코드를 다른 개발자한테 공개적으로 선보이고 검증받는 자생적인 생태계가 자리 잡혀 있었습니다. 특히 지금까지도 사용하고 있는 React도 오픈소스 라이브러리라는게 아직도 믿기지가 않곤 합니다. 

 

저는 개발을 처음 접했을 때부터 지금까지 개발자가 되고 싶은 이유가 한결같습니다. (낭만이 한 컵 들어갔지만요)

 

언젠가 오픈소스 저자가 되어 다른 개발자들과 오픈소스 생태계에 기여를 하자

 

하지만 '오픈소스'라는 키워드를 제외하곤 저는 아직까지 오픈소스를 실제로 구경해본 경험조차 없습니다. 기본적으로 오픈소스의 구성원으로 'Author > Maintainer > Contributor'가 있다고 생각합니다. 물론 Maintainer와 Contibutor 사이에도 여러 구성원이 활동하고 있지만 당장의 저의 목표는 Contributor가 되어 오픈소스 기여를 시작하며 전체 오픈소스의 구조를 배우는 것입니다. 

 

그러면 이제 기여할 오픈소스를 선택해야합니다. 처음에는 당연히 React, Next.js, Jest와 같은 대규모 오픈소스에 관심을 가졌습니다.

하지만 최근에 '카토 다이시'님의 포스팅과 활동을 지켜보며 Zustand라는 오픈소스 라이브러리에 관심을 가지게 되었습니다. 

보다 구체적으로 Zustand를 선택한 이유는 다음과 같습니다.

1. Zustand는 Poimandres 라는 Open source developer collective의 프로젝트에서 시작했습니다. 해당 Organization의 대표적인 오픈소스로 Jotai가 있습니다. 

2. Zustand는 현재 프론트엔드 상태관리라이브러리의 최전선에 있지만 아직 부족한 부분이 많이 있습니다. 대표적으로 TypeScript 관련 이슈가 몇가지 있습니다.

3. Maintainer인 '카토 다이시'의 블로그 포스팅을 통해 Zustand와 관련한 이슈를 확인할 수 있습니다.

4. 무엇보다도 마스코트가 너무 귀엽습니다 🥰

 

앞으로의 포스팅은 학습 내용 정리 및 Contributing log 위주의 포스팅이 될 거 같아서 이번 포스팅의 서론으로 '왜' 오픈 소스 컨트리뷰트에 관심을 가졌고, '왜' Zustand를 선택했는지에 대해 가볍게 이야기하였습니다.

 

이제 본격적으로 오픈소스를 뜯어보기에 앞서 Zustand를 fork한 후 첫 테스트를 실행해보겠습니다.

 

Zustand에서 제공하는 Contributing Guidelines를 읽어보자

무작정 오픈소스를 분석하기 보다는 우선 각각의 오픈소스에서 제공하는 Contributing Guidelines를 확인해보는 것이 좋습니다. 일반적으로 어느정도 규모가 있는 오픈소스는 Contributing 관련 Document를 제공하고 있습니다. 

Zustand에서 제공하는 Contributing Guidelines을 확인해보겠습니다. 저의 경우 아직 'Reporting Issues'나 'Suggesting new features'를 하기엔 실력이 부족하다고 생각되어 'Development'관련 부분만 확인해보겠습니다.

생각보단 시작은 순탄할지도 ?

이번 포스팅에선 Repository를 Fork하여 로컬 환경에 Clone하고, Dependencies를 설치한 후 yarn test를 통해 첫 테스트를 진행해보는 과정에 대해 다루겠습니다.

 

Fork한 레포지토리 클론하기

pmndrs/zustand 에서 Create a new fork를 통해 저의 깃허브 저장소에 Repository를 fork했습니다.

시작이 반이라고 벌써 대단한 일을 한거같다..!

 

위와 같이 fork가 성공적으로 이루어지면 git clone을 통해 로컬 환경에 clone해줍니다.

$ git clone 'fork한 repository 저장소 주소'

이 과정까지 순조롭게 진행하면 다음과 같이 로컬 환경에 Zustand를 clone할 수 있습니다.

오픈소스 저자가 곰을 엄청 좋아하나봅니다. 아예 .jpg파일이 있네요 !

 

Dependencies 설치하기 전에 package.json 구경하기 !

Zustand의 Dependencies를 설치하기 위해선 터미널에 yarn 만 입력하면 됩니다.

하지만 그 전에 package.json을 뜯어보며 내부구조를 알아볼까요?

아직 제대로 보는 요령은 따로 없어서 제가 기억해두면 좋을거같은 내용 위주로 확인했습니다.

솔직히 말해서 pakage.json에서 exports는 처음보는 거 같습니다. 하지만 대략적인 느낌으로는 해당 부분을 통해 전체 구조를 알아볼 수 있을 거 같습니다. 하나의 경로에 대해 import, module, default가 있고 가리키는 경로의 양식이 전부 비슷해보이네요. 

rollup이 뭘까..?

Zustand에선 어떤 커맨드로 작업을 진행하는지 궁금해서 scripts를 확인해봤습니다. 여기서도 살짝 벽이 느껴지는 느낌이 드네요.. 처음부터 다 기억하는 건 욕심이라 생각해서 딱 두가지만 알아두고 넘어갔습니다. 

1. rollup 이라는걸 많이 쓰는구나, rollup 에 대해선 꼭 공부해보자 !

2. test에는 vitest를 사용하는구나, vitest 에 대해서도 꼭 공부해보자 !

 

익숙한 이름이 보인다.

오픈소스의 pakage.json에는 저자와 컨트리뷰터(아마 메인테이너인거 같습니다)의 이름도 적어주는 거 같습니다.

devDependencies 스크립트 길이가 살벌합니다..

이쯤되니 살짝 포기하기 싶은 마음이 올라오네요.. 하지만 앞서 말했듯이 이번 포스팅에선 중요해 보이는 것 위주로 간단하게 체크하고 넘어가보겠습니다. 제가 정리한 중요 포인트는 다음과 같습니다.

1. dependencies는 1개만 사용하고 대부분 devDependencies를 사용합니다. 

2. babel, rollup, eslint 관련 plugin이 절반 이상을 차지합니다.

3. typescript를 사용합니다.

처음부터 다 소화하려하기보단 위의 내용만 일단 기억하고 넘어가보는걸로 하겠습니다. 

너는 누구니 peerDependencies !

peerDependencies는 정말로 처음들어봅니다. 우선 용어부터 정리해보겠습니다. 

• Dependencies

앱에 종속된 가장 일반적인 종속성입니다. 런타임과 빌드타임, 개발중 모두에서 이 종속성 패키지들이 필요하기 때문에, 앱이 빌드 될 때 이 종속성 패키지들이 번들에 포함되어 배포됩니다.

• devDependencies

런타임에서는 필요하지 않고 빌드타임 & 개발중에만 필요한 패키지들입니다. 빌드타임에서 이 종속성들은 빌드에 도움을 주거나 참조가 되지만, 번들에는 포함되지 않습니다.

• peerDependencies

실제로 패키지에서 직접 require(import) 하지는 않더라도 호환성이 필요한 경우 명시하는 종속성입니다. 여기서 Peer 는 "동료" 라는 뜻을 가지고 있습니다.

 

예를 들어 my-app 에서 사용하기 위한 React 기반의 컴포넌트 라이브러리인 my-ui-library를 개발한다고 가정해보겠습니다. 이 때 UI Library 에서는 react 17.0.0 버전을 peer dependancy로 두고 있습니다.

my-ui-library는 react컴포넌트의 라이브러리이기 때문에, 이 라이브러리를 사용하게 될 프로젝트에서는 react를 의존할 수 밖에 없습니다. 이러한 경우에 peerDependencies를 사용합니다.

즉, '이 라이브러리를 사용하게 될 프로젝트에게 react ^17.0.0 버전을 사용해주세요 !' 라고 알려주는 것과 비슷하다고 생각하시면 됩니다.

// my-ui-library package.json
"peerDependencies": {
  "react": "^17.0.0",
}

우선 peerDependencies에 대해선 여기까지만 알아보도록 하고, Zustand는 immer, react, @types/react를 peerDepencies로 두고 있구나 정도만 기억하고 넘어가겠습니다.

 

package.json에서 알아보고 싶은 내용은 다 알아본거같습니다.

이제 한번 Dependencies를 설치해볼까요 ? 

$ yarn

잠깐의 시간이 지난 후 node_modules폴더가 생성된 것을 확인할 수 있습니다.

 

Fork한 시점 기준으로 testing을 진행해보자

Contributing 가이드라인에선 yarn test:dev 명령어로 첫 테스트를 진행해볼 것을 권장하고 있습니다.

yarn test:dev 명령어를 터미널에 쳐보겠습니다. 

not found..? 어째서..?

시작부터 당황스럽네요. 저의 든든한 아군 package.json의 scripts로 가볼까요 ?

test랑 test:ci만 있네요,,

일단 여기서 저의 추측은 이렇습니다.

 

원래는 yarn test:dev로 테스트를 진행했지만 yarn test 와 yarn test:ci 로 script 변경 이후에 Document를 업데이트 안했구나 ! 

 

물론 전적으로 저의 추측이기 때문에 제가 놓치고 있는게 있을 수 있습니다. 한번 yarn test 명령어를 사용해볼까요 ? 

왜 처음에 안깔렸니,,

@vitest/coverage-v8을 설치하라는 문구가 올라와 추가로 설치해줬습니다. yarn 명령어로 의존성을 설치했을 땐 왜 설치가 안되었는지는 의문이지만 일단 잘 설치된 거 같네요.

설치 완료 후 다시 yarn test 명령어를 실행하였습니다.

터미널에 명령어를 입력하니 다음과 같이 터미널 동작한 후 웹 브라우저 vitest 페이지를 통해 test 결과를 확인할 수 있었습니다.

물론 터미널에도 test결과가 표시되지만 vitest 페이지에서 보는게 눈이 더 행복하네요 😊

UI 대박,, vitest 너 정체가 뭐야..!

마치며

지금까지 Zustand를 fork한 후 첫 테스트를 실행해보는 과정을 소개드렸습니다. 

 

어느 개발자에게나 비슷하겠지만 오픈소스 공부를 시작하는 것은 하나의 '벽' 처럼 다가오곤 합니다. 저 또한 항상 말만 하다가 이번에 와서야 Zustand를 fork하게 되었네요. 막상 Zustand를 clone하여 오픈 소스 공부를 시작하니 한결 홀가분한 마음이 듭니다. 만약 저처럼 오픈 소스가 주는 압박감에 시작도 못하신 분이 계시다면 이번 기회에 관심이 있는 오픈소스를 fork해보시는 것 부터 시작해보시는 걸 추천드리겠습니다. 

 

향후 Road To Contribute 의 방향은 크게 3가지로 나뉠 거 같습니다.

먼저 dependencies에서 확인했던 babel, rollup, eslint, vitest 에 대해 심화 학습을 진행하여 기록할 예정입니다.

다음으로 오픈 소스를 시작하는 가장 좋은 방법 중 하나인 'Test Code'를 확인해보며 오픈소스에 대한 이해도를 높일 예정입니다.

마지막으로 관심이 가는 Issue가 등록되면 TDD 방식으로 이슈를 처리하여 PR하는 과정을 담아내려 합니다.

 

오픈소스에 대한 공부는 처음이라 많이 서툴고 공개하기 부끄러운 마음이 드네요. 그래도 제가 고민했던 흔적을 남겨놓는게 다른 개발자들에게도 좋은 영감이 될 거라 믿고 열심히 기록해보도록 노력하겠습니다.

 

 

참고

https://velog.io/@johnyworld/Peer-Dependencies-%EC%97%90-%EB%8C%80%ED%95%98%EC%97%AC 

Peer Dependencies 에 대하여