모노레포와 tooling에 대한 고민들....🤧

모노레포에 대한 고민들

• 모노레포는 결국 여러 패키지/앱 간에 동일한 설정과 코드를 공유하는데 최적임은 틀림없다.
• 그렇다면 각 패키지/앱 간에서 사용되어야 할 의존성들이 분리되어야 할 때를 맞이하면 어떻게 해야할까?
  • ex. 앱 A 에서는 next.js 14 버전을 사용하고 앱 B 에서는 next.js 12 버전을 유지하고싶다면?
  • 혹은 앱 A에서만 앵귤러를 유지하고, 다른 앱에서는 React 를 사용하고있다면? 워크스페이스 전체의 의존성에 앵귤러가 포함될 필요가 있을까?
• 이를 해결하기 위한 방법으로 nx 에서도 single package.json 을 v15 부터 지원했다. (yarn workspaces 도 지원한다.)
• 그러니까 워크스페이스 전체에서 package.json 을 관리하고, 모든 앱/패키지에서 동일한 의존성을 참조하는 것은 모노레포의 큰 장점일 수 있으나, 모노레포 내의 앱/패키지의 수가 많아지고 그 각 앱/패키지 별로 의존성이 달라질 경우에는 단점이 되버린다.
• 따라서 이러한 단점을 개선하기 위한 방법으로 single pacakge.json 을 지원한다고 생각한다.
• 다만, 각 패키지/앱 간에서 사용되어야 할 의존성들이 분리되어야 할 때 (앱A에서는 next.js 12 / 앱B에서는 next.js 14)를 겪어본 결과, 궁극적으로 모노레포 툴만으로는 극복하기 어려운 케이스가 있음을 깨달았다.
  • 워크스페이스 내의 nx 코어를 최신버전으로 마이그레이션 할 경우 관련한 빌드 플러그인 (nx/next 등) 도 마이그레이션이 되어야한다. (해당 플러그인의 동작이 nx 코어에 의존하므로)
  • 그런데 Next.js12 에서는 최신버전의 nx/next 플러그인이 동작하지 않는다.
    • 왜? Next.js 13 버전 이상부터 next.config.js 에서 추가된 필드들이나 변경된 부분이 있기 때문에
  • 그렇다고 해서 Next.js12 버전의 앱을 위해서 구버전의 빌드플러그인을 사용할 수도 없는 노릇이다. (어차피 구버전 빌드 플러그인은 업그레이드한 nx 코어 버전과 호환되지 않아서 동작안함.)
  • 그렇다면 이런 케이스 두 가지의 해결 방법이 있다.
    • 모노레포 내의 Next.js 버전을 다같이 올리거나
    • nx 코어 최신버전을 사용하되, next.js 12 버전 이하를 지원하는 별도의 플러그인을 직접 개발하여 일부 앱에 적용해놓거나.
• 이 문제는 결국에는 Next.js 의 메이저 업그레이드의 범위가 커서 발생한다고 결론지었다. 이렇듯 버전에 예민한 라이브러리들은 참 다루기 어렵다는 것을 이번에 깨달았다..
• https://github.com/nrwl/nx/issues/1777

모노레포의 단점들을 개선하기 위한 툴링들

• CI/CD 에서 코드를 다운받는 시간 줄이기
  • 경량 체크아웃
  • git sparse-checkout init --cone
  • git sparse-checkout set 디렉토리
  • CI/CD 파이프라인에 적용해볼 수 있을듯.
• 의존성 관리하기
  • 같은 레포지토리와의 의존관계를 정리하자.
  • nx 에서는 의존성 그래프를 사용하여 감시하여도 좋고, 현재 작업에서 영향있는 (affected) 패키지들을 알려주는 장치가 있으면 좋다.
• 여러 패키지 / 앱 간의 태스크를 여러번 수행하는 것
  • 빌드 태스크를 캐싱하기
  • nx는 리모트캐싱/ 클라우드캐싱을 이용해볼 수 있다.

Ref- https://maxkim-j.github.io/posts/monorepo-tooling/