루트 단일 설치 vs 워크스페이스 설치

회사 모노레포에서 Yarn을 쓰고 있고, 일렉트론 구조라서 각각의 렌더러에 모두 동일한 라이브러리들이 설치되어 있어, 루트에만 두고 하위 워크스페이스에서 peerDependencies로 가져오는 방식에 대한 의견이 있었는데, 나도 확신이 없어서 관련된 내용들을 찾아보았다.
( + 전 회사에서는 루트에서 override로 통제하는 식으로 썼는데, 지금 회사와의 다른 구조가 있을 수도 있어 확신이 없기도 했다.)

결론

초기엔 편하지만, 규모가 커질수록 루트 단일 설치는 랜덤성과 유지보수 비용을 키우기 때문에, 버전 정책은 루트에서 통제하고, 설치/사용은 각 워크스페이스가 명시하는 패턴이 가장 안정적이다.

이유

1) 유령 의존성 막기
앱마다 package.json에 A/B/C를 직접 적어두면, 누락된 건 바로 "Cannot find module" 에러로 나타나기 때문에, 디버깅이 간단해진다.
2) 빌드 툴이 찾는 위치 문제
Vite나 PostCSS는 현재 워크스페이스 기준으로 플러그인을 찾는데, 만약 앱 쪽에 A/B/C가 없으면 가끔 해석이 꼬일 수도 있다고 한다.
그래서 렉트론처럼 렌더러가 여러 개인 구조라면, 각자 명시하고 공용 설정만 공유하는 쪽이 훨씬 안정적!

따라서 위와 같은 이유로 아래와 같이 구조를 변경하였다.

• 공용 설정만 패키지화: library/config-*
  • 여기서는 peerDependencies로만 요구
• 각 앱(app/renderer-a, app/renderer-b)은 devDeps에 A/B/C 직접 설치
• 루트에서 버전만 강제함.

{
  "resolutions": {
    "a": "8.4.47",
    "b": "3.4.14",
    "c": "10.4.20"
  }
}

resolutions / constraints 차이

resolutions

• 버전 override 도구
• 트리 어딘가에서 쓰이는 의존성 버전을 루트에서 강제로 고정한다.
• package.json 안에 "resolutions": { "react": "18.3.1" } 이렇게 적으면, 모든 워크스페이스/모든 transitive deps가 react@18.3.1로 통일된다.
• npm의 overrides랑 비슷한 개념.

장점: "하위에서 react@18.2 요청했어도 무조건 18.3.1을 설치해라" 같은 긴급 패치/보안 핀 고정에 유용.
단점: "각 워크스페이스가 react를 선언해야 한다" 같은 규칙은 강제하지 못함.

constraints

• 정책/규칙 엔진
• 어떤 워크스페이스가 어떤 의존성을 가져야 하는지, devDeps에만 있어야 하는지, 버전 범위는 어떤지 등을 룰로 강제함.
  ex) 모든 워크스페이스가 react를 쓴다면 반드시 ^18.3.1 범위를 써야 한다

gen_enforced_dependency(WorkspaceCwd, "react", "^18.3.1") :- 
  workspace_has_dependency(WorkspaceCwd, "react").

장점: 규칙 위반을 CI에서 잡아내고, 팀 차원의 합의를 강제할 수 있음.
단점: 선언만 해놨는데 transitive dep에서 버전 충돌이 나면, 결국 resolutions 같은 걸로 override 필요함.

https://stackoverflow.com/questions/51235261/why-does-yarn-warn-when-adding-a-dependency-to-the-root-workspaces-package-json

https://yarnpkg.com/configuration/manifest#resolutions

https://yarn2.netlify.app/features/constraints

https://yarnpkg.com/features/workspaces