monorepo 구조에 storybook을 적용하며...

프레임워크 : React + typescript

번들러 : vite
패키지 매니저 : yarn

모노레포 구조에 storybook을 적용하며 많은 트러블 슈팅을 해야만했다.

과정에 대해서는 생략하고 중요하게 느낀 점이 있다.

전에는 tsconfig와 vite.config에 대해 매우 얕은 지식만 가지고 있었고, 다른 이가 세팅해둔 탬플릿 위에서 작업을 해서 큰 문제를 겪지 못했지만 이번에는 내가 세팅을 맡은 입장이 되었다.

작년 말 회사에서는 Front 구조를 Monorepo로 바꾸자는 의견이 있었고, 훌륭한 어떤 개발자가 Monorepo 구조로 Template을 만들었다. 현재 프로젝트에서는 해당 Template을 활용하여 진행하기 시작하였지만, 나는 각 workspaces 에 속하는 패키지들이 각각 dev-server를 띄워야 한다고 생각하고 있었다.

 

이렇게 생각한 이유를 설명하기 전에 브랜치 구조에 대한 설명이 필요하다.

현재 main(운영), dev(개발) 브랜치를 같은 level에 두고 있으며 feature 폴더 하위에 각 메뉴별 브랜치를 두고있다.

workspaces 에 속하는 패키지들이 각각 dev-server를 띄워야하는 이유

1) 각 메뉴별 리더가 dev에 push하도록 내부 rule을 정하였지만, 허가 받지 않은 누군가 dev브랜치에 바로 push할 위험이 있다. 현재 부모 프로젝트가 dev-server를 띄우는 상황인데, 앞선 상황과 같은 일이 발생하여 dev-server를 에러로 인해 실행하지 못할 수 있다.

(물론 merge request라는 기능이 있지만, github, gitlab 이외에 존재하는지 모르겠다. 온전히 git의 기능인지도.. 아직 제대로 찾아보지 않았다! (이 부분에 대한 학습이 필요!))

 

2) 만약 각 패키지에서 dev-server를 띄우려해도 router 설정등 많은 것을 만져야한다.

 

 

위와 같은 이유로 각 패키지에서 storybook을 띄워 view component 단위로 보는 것이 낫다고 판단하였다.

 

storybook 을 적용하면서 yarn workspaces 가 어떤 방식으로 패키지들을 컴파일 하는지 알 수 있었고 (symlink 생성 및 file-system을 통해 가져온다), 패키지들의 절대 경로가 절대 동일해서는 안된다는 것, 번들링을 위한 alias 별칭 설정 등 정말 많은 것을 배울 수 있었고, 생각할 수 있게 되었다. 현재는 tsconfig의 paths 필드와 vite config의 alias 설정에 대해 익혔지만, 아직 다른 필드나 속성들에 대해서는 부족하다.  (순서 : 번들링 -> 컴파일)
아! filesystem을 이용하기 때문에 각 패키지들은 vite config에서 alias를 tsconfig의 paths 와 동일하게 설정해줄 필요가 없다. 각각 번들링 되지 않기 때문이다(현재 내 생각). 대신 부모 프로젝트의 vite config에서 workspaces의 패키지들의 alias를 설정해줘야 한다! 그래야 번들링이 제대로 될 것이다.

paths와 alias를 설정해줬음에도 부모 프로젝트에서 IDE의 자동 import의 도움을 받으면 paths에 설정된 경로로 자동완성이 되버린다.

node_modules에서 꺼내서 써야하는데 말이다. 그래서 paths설정을 바꾸면 또 build Error가 발생한다.
참으로 진퇴양난이다. 아직 해결 방법은 못 찾았으며 찾아 나아가겠다.

 

현재 자세한 내용은 따로 작성 중이며 온전히 작성히 완료되면 올릴 예정이다.