들어가기 전...
- 멀티레포의 장점과 단점
장점 : 1) 각 프로젝트가 고유의 저장소를 가짐 = 다른 프로젝트와의 의존성 x = 독립적 & 빠른 개발이 가능. 2) 비교적 크기가 가벼워 프로젝트 관리 면으로 수월함.
프로젝트가 많아질수록 아래와 같은 문제점이 발생..
단점 :
1) 각 프로젝트의 코드 컨벤션이 통일하기가 어려워
2) 각 프로젝트별로 사용하는 모듈 및 버전 스택이 달라질 수 있습니다.
3) 오랫동안 건드리지 않은 프로젝트의 관리가 힘들어지며,
4) 시간이 지날수록 해당 프로젝트의 Legacy 파악이 어려워질 수 있습니다.
5) 팀원별 컨텍스트 공유가 서로 원활하지 않을 수 있습니다.
mkdir root폴더 (기존 작업폴더에서 마이그레이션 해도 돼)
yarn init -y
root에 작업을 모아둘 폴더 만들고 그 안에서 프로젝트 생성
root디렉토리의 package.json과 하위 프로젝트 package.json들 수정 (아래참조)
터니널에서도 이렇게 확인되면 성공!
// root - package.json
{
"name": "my-root",
"version": "0.1.0",
// "license": "MIT", // 사용 조건을 나타내는 라이선스를 지정
// MIT : 매우 자유로운 라이선스, 코드 수정, 배포, 상업적인 용도로도 사용 가능.
// monorepo를 위한 설정부분
"private": true,
"workspaces": {
"packages": ["packages/*"],
// = "workspaces": ["workspace-a", "workspace-b"]
🟢 "nohoist": [
"react-native", "react-native/**"
// 모든 패키지의 node_modules에 있는 react-native 및 react-native의 하위 요소들을 hoist에서 제외하고 각 패키지 내부에 설치한다는 뜻
// 각 패키지가 필요한 버전의 React와 React DOM을 독립적으로 관리할 수 있다.
]
}
}
...
├─ services
│ ....
│ ├─ service-a
│ │ ├─ .eslintrc
│ └─ services-b
│ └─ .eslintrc
...
└─ .eslintrc
이런식으로 eslint도 유연하게 관리 가능.
yarn에서는 별도로 Hoisting이 되지 않도록 noHoist 옵션을 제공 , Monorepo에서 의존성을 어떻게 설치할지 제어하는 옵션.
yarn workspace 내 root node_modules로 Hoisting 된 모듈들은 하위 프로젝트에서 모두 액세스 할 수 있는 것처럼 보일 수 있습니다. 그러나 각 하위 프로젝트를 실제로 Build를 시도할 때 특정 모듈은 해당 로컬 node_moduels만을 참조하려는 경우가 많습니다. 이때 root node_modules로 Hoisting 된 모듈은 로컬 node_modules에는 실제로 존재하지 않기 때문에 not Found 에러가 발생하게 됩니다.
일반적으로 Yarn Workspaces는 공통 의존성을 프로젝트의 최상위 node_modules 디렉토리로 hoist하여 중복된 의존성을 최소화하려고 시도
nohoist를 사용하면 각 프로젝트의 의존성 모듈을 프로젝트 내 각 로컬 node_modules에 설치되기 때문에 이러한 의존성 문제를 해결할 수 있다.
면 특정 패키지의 의존성을 상위 레벨 노드 모듈로 hoist(끌어올림)하지 않고, 각 패키지 내의 node_modules 디렉토리에 설치할 수 있습니다.
특정 상황에서 이 동작이 원하는 대로 작동하지 않을 수 있습니다. 이때 "nohoist"를 사용하여 특정 패키지의 의존성을 hoist에서 제외할 수 있습니다.
일반적으로는 Yarn Workspaces의 기본 동작이 원하는 결과를 제공하기 때문에 특별한 상황이나 요구사항이 없는 한 굳이 사용할 필요는 없습니다.
출처1 (yarn workspace)
출처2 (콴다 개발블로그 - 모노레포 )
출처3 (테스트뱅크 개발블로그 - 모노레포)