Jung Han

Follow

Sep 1, 2019 · 17 min read

시작하기 전에

이 글은 FE개발랩 오픈소스 프로젝트 mono-repo 도입을 위해 조사했던 내용을 조금 다듬어 공유용으로 작성한 글입니다.

이미 Mono-Repo를 적용해서 많은 꿀팁을 갖고 계시거나 잘못된 내용이 있다면 댓글 부탁드립니다.

`Multi Repo`와 `Poly Repo`는 같은 의미로 사용되는 단어입니다. 이 글에서는 좀 더 범용적으로 쓰이고 있는 `Multi Repo`로 통일 시켜 작성했습니다.

Mono-Repo와 Multi-Repo?

Mono는 단일의 의미를 나타내는 접두사입니다. 반대의 의미로는 Multi, 복수일 것입니다. 또한, Repo는 Repository의 줄임말로 저장소를 의미합니다. 두 단어를 합쳐보면 Mono-Repo의 범용적 의미를 알 수 있습니다.

Contains multiple packages or projects
Multi-Repo는 여러 저장소에 프로젝트, 패키지를 분산해 두는 것을 의미합니다.
정반대로 Mono-Repo는 하나의 repository(저장소)에 여러 프로젝트, 패키지를 가진 것을 의미합니다.

Mono-Repo의 장점이자 Multi-Repo의 단점

Multi-Repo는 유연성, 배포, 확장이 쉽습니다. 또한, 정책을 정하거나 책임을 명확하게 팀원들에게 맞게 분배할 때 저장소를 분리하는 것이 좋습니다.

하지만, 새로운 프로젝트를 시작할 경우 중복된 설정을 매번 해줘야 하며 오픈소스를 운영할 때에는 이슈가 분산되고 중복되는 코드 배포가 잦을 수 있습니다.

그럼 이제 Mono-Repo의 장점을 하나하나 살펴보겠습니다.

# Common config
Multi-repo는 모든 설정을 각각 프로젝트마다 갖게 됩니다. 하지만 Mono-repo에서는 `ESLint`, `Prettier`, `Babel` 등의 설정을 루트 레벨에 할 수 있어 여러 패키지에서 하나의 설정을 공유할 수 있습니다.

# 코드 재사용

또한, 패키지를 넘나들며 모듈화 시켜 사용할 수 있습니다.

여기서 `babel/packages/babel-cli/src/babel/util.js` 경로에 들어가 코드를 보면

// … 다른 모듈 import
import * as babel from “@babel/core”;
export function transform(
  filename: string,
  code: string,
  opts: Object,
): Promise<Object> {
  opts = {
   …opts,
   caller: CALLER,
   filename,
  };  return new Promise((resolve, reject) => {
   babel.transform(code, opts, (err, result) => {
    if (err) reject(err);
    else resolve(result);
   });
  });
}

@babel/core 의존을 가져와 사용할 수 있습니다.

간단하게 만들어본 Mono-Repo의 예시입니다. 공통으로 사용하는 core, util, routing 코드들을 각 패키지로 분리하고 이 패키지를 이용해 하나의 어플리케이션을 만들 수 있습니다. 또한, 이 core, util, routing은 이 자체로도 의미가 있어 외부에서 사용을 할 수 있도록 배포될 수 있습니다. 마치 TOAST UI의 tui-code-snippet, tui-dom 처럼요!

# One PR

TOAST UI Application + TOAST UI Component + React Wrapper + Vue Wrapper 의 갯수는 몇개일까요?

답은 41개입니다. 얼마 전 실제로 있었던 일입니다. 사명이 NHN Entertainment에서 NHN으로 변경되었을 때 사명이 변경된 것을 npm에 반영시키려면 41번의 배포가 필요했습니다.(repository의 변경은 조금 더 뒤에 있었으니 더 많은 횟수의 배포가 있었습니다.) 물론, 다른 오픈소스들에 비해 많은 개수는 아니지만 그래도 적지 않은 갯수이기는 합니다.(1000개 이상의 모듈을 npm에 등록하신 분도 존재합니다.) 적어도 TOAST UI의 각 어플리케이션에 래퍼들을 통합시켜 Mono-Repo 형태를 만들어준다면 10개의 저장소 관리 이슈가 줄어들고 하나의 PR로 많은 것을 한 번에 관리할 수 있게 될 것입니다.

TOAST UI Grid는 지금 어떻게 하고있나?

TOAST UI Application은 지금 multi-repo의 형태를 띄고 있습니다. TOAST UI Grid를 예로 들면(나머지 Application 또한 마찬가지입니다.) tui.grid, toast-ui.vue-grid, toast-ui.react-grid 세개의 저장소로 분리되어 있습니다.

# 관리의 불편함

1. 🌟이슈의 분산🌟: 이슈가 분산되는 것은 가장 큰 문제였습니다. TOAST UI Grid를 vue-wrapper를 통해 사용할 때 문제가 생긴다면 어느 저정소에 이슈를 올려야 하는지 사용자는 충분히 헷갈릴 수 있습니다. 또한 지켜봐야 할 저장소가 많아질 수록 빠른 대응이 힘들어지는 것 또한 현실이었습니다.
2. 매번 프로젝트를 생성할 때마다 정적분석도구나 스타일 규칙을 매번 설정해줘야 했습니다.(Prettier, Eslint, Cypress, storybook…)
3. 의존을 갖고있는 레포를 수정했을 때 모두 한꺼번에 수정하여 배포하기에 어려움이 있었습니다.

이런 불편한 점은 정확하게 mono-repo의 장점과 매칭되었습니다.

Mono-Repo의 필요성과 장점들을 간단하게 알아봤으니 저장소 구성을 도와주는 한 오픈소스를 소개해보겠습니다.

Lerna 란?

Lerna는 러나 혹은 레르나로 읽힙니다. 한국에서는 레르나로 더 많이 읽히는데요. (로고의 히드라가 궁금하시면 위키를 참고해주세요.)
Lerna는 단일 저장소(Repository)에서 다양한 packages를 구성하는 것을 도와주는 라이브러리입니다. 프로젝트 전체를 빌드하거나, 테스트 할 때 변경이 있는 패키지들을 배포할 때 도움을 줍니다.

Lerna로 무엇을 할 수 있나?

Lerna에서 공식사이트에서 언급하기로는 lerna publish, lerna bootstrap 두가지가 주요 기능이라고 합니다. 본격적으로 사용한 것은 아니지만 이외에 많은 기능을 한번에 제공하고 있습니다. 이제 여러 커맨드들도 같이 보도록 하겠습니다. 구체적인 커맨드 설명이나 여기 등장하지 않는 커맨드가 궁금하다면 다음 링크를 확인하세요.

# lerna init

$ lerna init
$ lerna init — independent

해당 프로젝트에 lerna repo를 만들거나 최신 버전으로 업데이트를 할 때 사용합니다. — independent 옵션을 붙일 경우 패키지들의 버저닝 정책을 독립으로 가져갑니다.

# lerna version

$ lerna version 1.0.1 # explicit
$ lerna version patch # semver keyword
$ lerna version # select from prompt(s)

이전 배포 버전에서 변경이 존재하는 pacakge들의 버전을 변경시켜줍니다. semver 키워드를 입력시키거나 버전을 명시해주거나, 선택해서 적용시킬 수 있습니다.

# lerna diff

$ lerna diff [package]

해당 패키지의 지난 배포 이후 변경점에 대한 내용을 보여주게 됩니다.

# lerna bootstrap

$ lerna bootstrap

lerna bootstrap을 통해 각 패키지들의 의존을 설치하고 cross-dependencies를 연결, 재정비 해줍니다. 의존이 있는 패키지는 설치 대신 Symlink를 정비 합니다.

# lerna run

$ lerna run <script>
$ lerna run test
$ lerna run build# my-component 패키지만 test
$ lerna run — scope my-component test

각 패키지들의 npm 명령어를 실행합니다. scope를 지정할 수 있으며 scope를 지정하지 않을 경우 전체 패키지에 명령어를 수행합니다.

# lerna publish

$ lerna publish

프로젝트에서 지난 릴리즈 이후 변경이 있었던 패키지를 배포합니다.

# lerna clean

$ lerna clean

각 패키지들의 node_modules 폴더를 삭제합니다. workspaces를 사용하여 초기 설정을 구현할 때 사용하기 좋습니다.

# lerna link convert

$ lerna link convert

lerna link convert를 통해 각 패키지의 devDependencies를 루트에서 관리할 수 있습니다.

Mono-Repo 적용 해보기

* 테스트 깃헙 링크: https://github.com/jung-han/tt-grid-test

각 커맨드들을 간단하게 살펴봤습니다. 어떤 역할을 해주는 라이브러리인지 느낌이 오시나요? 그럼 한번 간단하게 적용해 보겠습니다.

독립버전

lerna를 설치하고 independent로 프로젝트를 구성했습니다.

$ lerna init — independent

lerna.json 파일은 lerna init을 한 상태 그대로 입니다.

{
 “packages”: [
 “packages/*”
 ],
 “version”: “independent”
}

각 패키지들의 경로가 어떻게 되는지, version은 어떻게 가져가는지를 나타내는 설정 파일입니다.

# 폴더 수정하기

packages 폴더에 각 패키지들을 위치 시킵니다. 이때 공통으로 묶을 수 있는 docs 파일이나 설정파일들을 root로 위치 시킵니다.

# 배포하기

npm publish를 하게되면 보게 되는 화면입니다. CLI를 통해 어떤 버전을 배포할 것인지 각각 패키지들 별로 버전을 지정해 줄 수 있습니다.

# 릴리즈 노트의 형태

독립버전 배포후 태그의 형태는 배포된 패키지의 이름@버전의 형태입니다. lerna publish를 이용하면 자동으로 태그를 만들어 줍니다.

# bower 사용하기

bower를 제공하는 방식은 동일합니다.

설정 파일을 packages의 어플리케이션의 번들파일 위치로 변경해주면 됩니다. 다만 `bower`의 기준은 프로젝트의 루트이며 여러 패키지를 각각 bower로 배포하는 것은 어려워 보입니다.(방법이 존재한다면..댓글 부탁드립니다ㅠㅠ)

통합버전

independent 옵션을 사용하지 않으면 이전과 다르게 버전에 숫자가 생기게 됩니다. 이 형태는 기본적으로 semver를 따릅니다. 이 옵션이 전체 package들의 통합 버전을 나타내게 됩니다.

{
  “packages”: [
    “packages/*”
  ],
  “version”: “0.0.0”
}

# 배포하기

이전 과는 다르게 변화가 존재하는 전체 패키지들을 버전에 맞춰 한번에 배포합니다.

릴리즈 노트 또한 이전처럼 하나로 관리되게 됩니다.

만약 react wrapper에 변화를 주고 배포를 한다면 변화가 있는 패키지만 배포되게 됩니다.

yarn workspace를 통한 code sharing

# 환경 설정

• lerna.json

{
  “packages”: [
    “packages/*”
  ],
  “version”: “0.0.0”,
  “npmClient”: “yarn”,
  “useWorkspaces”: true
}

각 pacakge의 코드를 공유하기 위해서는 yarn을 npm client로 지정해야 하며 useWorkspaces 옵션을 true로 지정합니다.

• root packages.json

{
  “workspaces”: [
   “packages/*”
  ]
}

최상단 packages.json에는 workspaces의 위치를 명시해줍니다.

yarn workspace를 사용하게 되면 각 패키지에서 사용하는 노드 모듈들을 중복으로 설치하지 않고 상단에서 관리할 수 있게 됩니다.

중복으로 사용하는 모듈 외에 파일들은 각 패키지들에 위치하여 사용됩니다. 해당 의존을 package.json에 명시하고 사용하면 정상적으로 동작하는 것을 볼 수 있습니다.

• yarn workspace를 사용하지 않고 lerna bootstrap을 통해서만 cross-dependency를 사용할 수 있습니다.
• npm 7 roadmap을 확인해 보면 7버전부터 workspace가 추가된다고 합니다. yarn을 굳이 사용하지 않아도 괜찮아 보입니다. (존버합시다)

오픈소스들의 버전 정책

만약 Mono-Repo를 도입한다면 가장 크게 고려할 점은 버전 정책일 것입니다. 각 오픈소스들은 각자의 서비스의 특성에 맞게 버전 정책을 정한 뒤 따르고 있습니다. 몇 가지 오픈소스들을 통해 사용할 수 있는 버전 정책을 검토해 볼 수 있을 것 같습니다. 각 오픈소스들의 버전 정책과 릴리즈 노트는 어떻게 작성되고 있는지, 그리고 어떤 정책을 선택해 볼 수 있을지 정리해봤습니다.

babel/babel

먼저, 모노레포를 가장 열심히 적용하고 있는 바벨입니다.

* 링크: https://github.com/babel/babel

# 버전 정책은?

바벨은 한가지 메인버전을 두고 커밋 디프가 존재하는 패키지를 배포합니다. 메인 버전이 하나 존재하며 배포가 있는 패키지는 그 버전을 따라갑니다.

위 그림을 보면 babel-node가 7.4.5 버전이 나갔을 때의 diff 입니다. 버전이 바로 7.2.2에서 7.4.5 로 뛴 것을 볼 수 있습니다.
각 패키지들을 독립된 프로젝트로 본다면 semver를 지키지 못한다고 볼 수 있습니다. 하지만, 하나의 큰 프로젝트라 생각한다면 매우 편한 정책이라 볼 수 있습니다.

# 릴리즈 노트는?

변경이 되는 내용과 영향을 받은 패키지들을 나열합니다.

facebook/react

* 링크: https://github.com/facebook/react

# 버전 정책은?

babel과 비슷한 정책을 추구합니다. 구체적인 정책은 알 수 없지만 주요한 기능이 되는 패키지들은 하나의 메인 버전을 따라갑니다. 독립적으로 버전을 주는 패키지들 또한 따로 존재 합니다.

# 릴리즈 노트는?

변경이 되는 내용과 영향을 받은 패키지들을 나열합니다.

facebook/jest

* 링크: https://github.com/facebook/jest

# 버전 정책은?

react, babel과 유사합니다. 아무래도 같은 계열의 프로젝트이기 때문이겠죠?

1. 모든 패키지들이 버전을 따라가지는 않는다.
2. 당시 업데이트가 있는(commit에 diff 가 있는) 패키지만 업데이트 하며 버전은 lerna.json을 따라간다.
3. patch 버전이 올라가는 경우는 거의 없으며 주로 minor 버전이 증가합니다.
4. major 버전이 빠르게 증가하는 이유도 이때문인 것 같습니다.

# 릴리즈 노트는?
깃헙에는 작성하지 않습니다.
마이너 버전, 패키지 단위의 업데이트는 따로 작성하지 않는다. 메이저 버전의 업데이트는 공식 사이트의 Blog 에 작성합니다.

airbnb/enzyme

* 링크: https://github.com/facebook/jest

react adapter를 react의 버전별로 관리하기 때문에 래퍼들을 관리하는 것과 비슷합니다.

# 버전 정책은?

independent 모드를 사용합니다. 각 패키지 별로 독립된 버전을 갖습니다.

# 릴리즈 노트는?

깃헙에는 작성하지 않습니다. 공식 사이트에 Change Log에 변동 사항을 각각 어떤 변동이 있는지 정리합니다.

가능한 버전 정책을 정리해보면?

세 가지 형태의 모델이 가능할 것 같습니다. 메인 버전을 두고 변화가 있는 패키지만 배포하는 모델, 전체를 모두 배포하는 모델, 각각의 패키지가 독립된 버전을 가져가는 모델입니다. 세 가지 모델은 프로젝트를 어떻게 구분하고 바라보는가에 따라 다를 것 같습니다.

첫 번째 모델은 lerna의 기본 모델입니다. 각 pacakge에서 변화가 있는 브랜치만 업데이트하는 모델입니다. 두번째 모델은 변화가 있는 브랜치에 맞춰 버전을 같이 올리는 경우인데 이 모델을 사용할때는 주로 의존을 갖고 있는 패키지의 `package.json` 파일에 업데이트 되는 버전의 패키지 버전을 명시해 변화를 줘 같이 업데이트 하는 방식을 따릅니다. 세번쨰 모델은 independent로 변화가 존재하더라도 각각 배포하게 되는 형태입니다.

준비한 내용은 여기까지 입니다. TOAST UI는 Mono-Repo 도입을 준비 중이고 결과적으로 어떤 장단점을 얻는지 다시 한번 정리하여 이후에 공유하도록 하겠습니다.

Mono-Repo는 오픈소스에서 규모가 커질 수록 필수가 되어가는 느낌입니다. 그리고 Lerna를 사용하지 않아도 Mono-Repo를 사용하고 있는 프로젝트 또한 쉽게 찾을 수 있습니다. 이후 Mono-Repo 적용에 도움이 되었으면 좋겠습니다. 읽어주셔서 감사합니다. 😃

참고

* https://www.youtube.com/watch?v=rdeBtjBNcDI