디자인 시스템, 형태를 넘어서
연사자 (flex - 이소영님)
예를 들어 하나의 Select 컴포넌트를 만들때 주로 이 두가지를 고민하게 된다.
1. SuperBigSelect
많은 prop을 관리하고 있음.
변경이 디자인 시스템의 책임이 늘어남.
복잡도 증가.
2. ManySelect
구현체 흩어지면서 파편화 이슈
일백개 패키지 모노레포 우아하게 운영하기
연사자 (토스 - 오창영)
- 모노레포
1-1. 정의"모노레포란 잘 정의된 관계를 가진,
여러개의 독립적인 프로젝트들이 있는 하나의 레포지토리이다"
Nwrl - Nx
1-2. 모노레포를 왜 사용해야 했을까요
멀티레포의 문제점
Project A와 비슷한 Project B를 만들때
1. 레포추가
2. ci/cd, lint, test, ts등의 설정을 해준다
3. Project A에서 쓰이던 코드를 재사용 하고싶을때 또 만든다.
- 새 프로젝트 생성 비용이 큼
- 프로젝트간 코드 공유가 어려움
- 같은 이슈를 수정하기 위해 각각의 레포지토리에 커밋이 필요
- 히스토리 관리의 어려움
- 제각각인 툴링으로 개발자 경험이 일관적이지 않음
모노레포가 해결해주는 것
- 새프로젝트 생성 비용이 적음
- 프로젝트간 코드 공유 쉬움
- 아토믹 커밋
- 히스토리 관리가 쉬움
- 공통된 툴링
-> 무조건 모노레포가 아닌 "잘 정의된 관계"를 가져야만 이로울 수 있다.
모노레포 features
속도
- 로컬 캐싱
- 로컬 태스크 오케스트레이션
- 원격 캐싱
- 변경된 프로젝트 감지
관리
- 프로젝트간 코드 공유
- 스캐폴딩을 통한 코드 생성
- 프로젝트간 의존성 관계를 설정
- 토스 프론트 라이브러리
토스 프론트엔드 챕터에서 공통으로 사용하는 내부 라이브러리 모노레포,
서비스 개발을 편하게 할 수 있도록 도와주는 100개 가량의 라이브러리로 구성
라이브러리 모노레포의 특징
토스에서 사용하는 모노레포 종류
1. Library Only Monorepo
커밋수 80+
배포 NPM
커밋당 영향범위 큼
2. Service Monorepo
커밋수 700+
배포 내부 인프라
커밋당 영향범위 작음
라이브러리 모노레포이기에 중요하게 생각해야하는 것들
기술적 요구사항
1. 의존성 관리
node_modules의 문제 -> 유령 의존성 -> yarn berry + pnp
peer dependency ? 패키지를 사용하는 곳에서 제공하는 dependency
2. 버전 관리
Semver (semantic versioning)
major - breaks API
minor - does not breaks API
patches - bug fixes
- 코드 품질 관리
RFC
ci에서 체크 - 문서화
라이브러리인 만큼 용법이 중요
JSDOC, docusaurus 사용
JSDoc을 달면 docusaurus에 등록 -> 문서화에서도 모노레포의 장점이 나타남
