0628

개발/스테이징 배포 눌러서 모두 내보내는데만 50분... 심지어 프로덕션(라이브)은 배포도 안했다.

물어보고 싶은거

1. 모노레포에서 의존성 관리를 루트 package.json에 몽땅 모아 관리하고 있는데 이게 좋은 방식인지 잘 모르겠다. Turborepo에서는 Install dependencies where they're used 하라고 권고하고 있고, 워크스페이스의 루트에는 몇 없는 의존성만 자연스럽게 남을 것이라고 얘기해주고 있다.

그들이 설명하는 장점으로는 다음 4개의 장점이 있다.

1. 깔끔하다(한 눈에 무슨 의존성이 필요한지 볼 수 있기 때문에)
2. 유연하다(ui팀은 최신버전의 타입스크립트를 쓰고 싶어하고 web팀은 안정성을 우선해 타입스크립트 버전업을 미루고 싶을 때 유연하게 대처할 수 있음)
3. 더 나은 캐싱 성능(의존성을 수정하면 루트에서 바뀌기 때문에 불필요한 캐시 미스가 광범위하게 난다)
4. 안쓰는 의존성 가지치기(도커 유저들은 도커 이미지로 필요한 의존성만 가볍게 유지할 수 있듯이, 각 패키지에서 의존성을 관리하면 Turborepo는 lockfile을 조회해 필요없는 의존성을 지울 수 있다)

3번은 토스와 같이 정말로 모노레포 안의 프로젝트 하나 당 한 팀이 달라붙는 거대한 조직에게 유효한 장점인 것 같다. 우리 회사처럼 소규모 조직의 몇 안되는 프론트엔드 개발자들이 단지 프로젝트들의 명확한 구분을 위해 모노레포 구조를 채택한 상황이라면, 모노레포지만 패키지 버전관리만큼은 중앙통제식으로 관리하고 싶은 니즈가 있을 것이다.

위 장점들을 반대로 생각하면(우리 회사의 방식대로 생각하면), 각 프로젝트별로 따로 의존성을 관리하게 되면 외부 의존성 버전 통일이 어려울 '수 있다'는 단점을 생각할 수 있다. 다음은 모노레포를 세팅해주신 분의 의도.

• 외부 라이브러리 설치는 무조건 최상단에서
• 각 apps 혹은 packages 내부의 package.json에 설치하지 말것.
  • node_modules 의존성이 어차피 어디에 설치하든 다 끌어올수 있음
  • 대혼돈을 막기 위해 외부 라이브러리 설치는 무조건 최상단에
    • 만약 각 apps 혹은 packages 내부에 설치하고 싶다면, 마찬가지로 빡센 토의 과정을 거쳐 엄선할 것
  • 현재 각 apps, packages에 설치된 라이브러리는 monerepo 초기 세팅 당시 자동으로 세팅된 것들 밖에 없음

It's up to the package manager to handle things like downloading the right external dependency version, symlinking, and resolving modules. The recommendations on this page are best practices for managing dependencies in a Workspace, and are not enforced by Turborepo.

Turborepo는 의존성을 관리하는 툴이 아니고 단지 각 워크스페이스의 의존성을 어떻게 관리할지 best practice를 추천해줄 뿐이며 그 책임은 패키지 매니저에 있다고 말한다. 또한 pnpm up --recursive typescript@latest 커맨드를 사용해 패키지를 한꺼번에 설치하고 관리할 수 있다고 얘기해준다.

그렇다면 패키지매니저인 pnpm의 문법을 이해할 필요가 있다.

2. Yarn Berry를 사용하면서 의존성 설치에서 큰 개선을 보려면 Zero install의 사용이 필요한데, 이는 git에 zip 파일로 관리가 되는 방식이며 의존성 자체가 git으로 관리되기 때문에 매번 의존성을 설치하거나 하지 않아도 되는 장점은 있습니다.  하지만 git에 모든 파일 기록을 저장하는 만큼 .git 디렉토리 자체가 무거워지며, PR을 만들었을 때 의존성이 변경되면 해당 파일들도 변경되기 때문에 코드 리뷰가 번거롭고 불편하다는 단점이 있죠. 토스는 이 단점을 어떻게 극복했는지?