# 기여하기

이 문서는 Bezier React에 기여하는 개발자를 위한 가이드를 제공합니다.

## 행동 강령

우리는 모든 기여자가 [기여자 행동 강령 규약](https://www.contributor-covenant.org/ko/version/2/1/code_of_conduct/)을 준수하길 기대합니다.

## 오픈 소스

이 프로젝트는 [채널코퍼레이션](https://channel.io/)에서 관리하고 있지만, 오픈 소스 라이선스 하에 공개되어 있습니다. 이는 외부 기여자들도 프로젝트에 참여할 수 있음을 의미합니다. 우리는 외부인의 기여를 환영합니다! 실제로 다양한 관점과 경험은 프로젝트를 더욱 성장시키는 데 큰 도움이 됩니다.

### 라이선스

이 프로젝트는 [Apache 2.0 라이선스](https://www.apache.org/licenses/LICENSE-2.0)를 따릅니다. 이 라이선스 하에, 어떠한 형태로든 코드를 사용, 수정, 배포할 수 있습니다.

## 유의적 버전 명세(SemVer)

우리는 사용자에게 안정적이고 예측할 수 있는 업데이트를 제공하기 위해 [유의적 버전 명세(SemVer)](https://semver.org/lang/ko/)를 따르고 있습니다. 명세에 따라 버전은 다음과 같은 규칙을 따라 증가합니다.

```md
주.부.수 (ex: 1.0.0)
```

1. 수(패치) 버전은 기존 버전과 호환되는 버그 수정에 따라 증가합니다.
2. 부(마이너) 버전은 기존 버전과 호환되는 새로운 기능 추가에 따라 증가합니다.
3. 주(메이저) 버전은 기존 버전과 호환되지 않는 변경 사항이 있을 때 증가합니다.

아래는 어떤 버전이 어떤 경우에 증가하는지에 대한 대표적인 예시입니다.

### 주 버전

- 컴포넌트 제거
- 컴포넌트의 속성 제거
- 기존 속성의 호환되지 않는 타입 변경
- 공개된 함수 및 믹스인의 호환되지 않는 변경

### 부 버전

- 새로운 컴포넌트 추가
- 컴포넌트에 새로운 속성 추가
- 기존 속성의 타입 확장
- 컴포넌트, 속성, 공개된 함수, 믹스인 등의 지원 중지(deprecated) 처리

### 수 버전

- 컴포넌트가 생성하는 HTML의 변경(클래스 추가, 제거, 이름 변경 등)
- 공개된 API에 영향을 주지 않는 변경
- 비공개된 함수 및 믹스인의 호환되지 않는 변경

### 호환되지 않는 변경(Breaking Change)

호환되지 않는 변경은 필수 불가결합니다. 하지만 호환되지 않는 변경 사항이 있을 때마다 주 버전을 증가시키는 건 버전 관리에 있어서 좋지 않습니다. 의존하는 프로젝트의 업그레이드 비용이 너무 크기 때문입니다.

우리는 먼저 지원 중지 처리를 하고, **다음 주 버전에서 실제 변경 사항을 적용**하는 방식을 사용하고 있습니다. 호환되지 않는 변경 사항을 처리하고, 지원 중지하는 과정에 대한 자세한 가이드는 [지원 중지 가이드라인](Deprecation)을 참고해 주세요.


### 실험적인 코드

안정화 단계가 아닌 컴포넌트들에 대해서는 유의적 버전 명세를 적용하지 않습니다. 즉, 실험적인 컴포넌트에 호환되지 않는 변경이 일어나더라도 주 버전을 올리는 것이 아닌 수(패치) 버전을 올리는 것을 원칙으로 합니다. 이 컴포넌트들은 컴포넌트의 이름에 `Alpha` 접두사를 가지고 있습니다. `bezier-react`의 주 버전을 올리게 될 때 해당 컴포넌트의 `Alpha` 접두사를 제거하게 됩니다.

## 브랜치 전략

기본 브랜치(`main`) 하나만 운영합니다. 이 브랜치에서 안정된 버전 배포가 이루어집니다. 이 브랜치에서 새로운 브랜치를 생성하고, PR을 보내는 방식으로 개발이 진행됩니다. 필요한 경우 `alpha` 나 `next` 같은 개발 브랜치가 추가되어 개발이 진행될 수 있습니다.

### 머지 전략

Squash and merge 전략을 사용하여 진행합니다. 각 PR이 하나의 커밋으로 표현되기 때문에, 커밋 히스토리가 깔끔해지는 장점이 있습니다. 추가적인 개발 브랜치를 운용하는 경우, 기본 브랜치로부터 주기적인 리베이스가 이루어질 수 있습니다.

## 이슈 제출하기

이슈를 통해 메인테이너 및 다른 기여자들과 의견을 공유할 수 있습니다. 개발하기 이전에 먼저 이슈를 검색해 주세요. 이미 해당 이슈가 존재한다면, 해당 이슈에서 논의를 진행해 주세요. 존재하지 않는다면, 새로운 이슈를 생성해 주세요.

### 버그 리포트

[템플릿](https://github.com/channel-io/bezier-react/issues/new?assignees=&labels=bug&projects=&template=bug-report.yml)을 통해 이슈를 제출해 주세요.

### 개선 사항 및 새로운 기능 요청

[템플릿](https://github.com/channel-io/bezier-react/issues/new?assignees=&labels=status%3Aneed+triage&projects=&template=feature-request.yml)을 통해 이슈를 제출해 주세요.

## 풀 리퀘스트(PR) 제출하기

PR이 생성되면 1. **프로젝트 메인테이너**와 2. **해당 변경 사항에 영향을 받는 코드의 코드 오너**가 코드 리뷰를 진행합니다. 모든 테스트를 통과하고, 리뷰어의 승인을 받으면 변경 사항을 머지할 수 있습니다.

**PR을 제출하기 전에** 꼭 다음 사항을 확인해 주세요.

1. 저장소를 포크한 후 `main` 브랜치에서 브랜치를 생성합니다.
2. 루트에서 `yarn` 을 실행하여 패키지를 설치합니다.
3. 테스트가 필요한 코드를 추가했다면, 테스트를 추가합니다.
4. `yarn test` 명령어를 통해 테스트 스위트가 통과하는지 확인합니다.
5. `yarn lint` 명령어를 통해 코드가 린트 규칙에 맞는지 확인합니다.
6. `yarn typecheck` 명령어를 통해 타입 검사를 진행합니다.
7. `yarn dev` 명령어를 통해 스토리북을 실행하고, 다양한 환경에서 테스트를 진행합니다.
8. 릴리즈가 필요한 변경 사항일 경우, `yarn changeset` 명령어를 통해 changeset을 생성합니다. [더 알아보기](#체인지로그-작성하기)
9. 포크한 저장소에 푸시합니다.
10. 포크한 저장소에서 원본 저장소로 PR을 제출합니다.

위에 해당하는 내용들은 PR 템플릿에 셀프 체크리스트로 일부 포함되어 있습니다. PR을 오픈하기 전에 모든 체크리스트를 확인하고 체크해주세요.

### 체인지로그 작성하기

`yarn changeset` 을 통해 작성하는 내용은 다음 릴리즈의 릴리즈 노트 및 소스 내부의 체인지로그에 포함됩니다. 아직 명확히 정해진 형식은 없지만, 다음과 같은 점들을 고려해서 작성해 주세요.

- [유의적 버전 명세](#유의적-버전-명세semver)에 따라 적절한 다음 버전을 선택합니다.
- 변경 사항에 대한 설명은 영문으로 작성합니다.
- 영문 대소문자를 지켜주세요.
- 자세한 구현을 모르는 사람도 이해할 수 있도록 작성해 주세요. (ex: `Fix a bug` -> `Fix a bug that caused the button to be rendered incorrectly when the screen size is less than 320px`)

#### 체인지로그를 추가할 필요가 없는 경우

라이브러리 사용자에게 영향을 주지 않는 변경 사항의 경우 체인지로그에 포함하지 않습니다. 개발 단계의 의존성 업데이트나, 린트 규칙 변경 등이 해당할 수 있습니다.

## 커밋 메시지 컨벤션

[AngularJS의 커밋 메시지 컨벤션](https://github.com/angular/angular.js/blob/master/DEVELOPERS.md#type)을 따라서 영문으로 작성합니다. 커밋 메시지의 타입은 다음과 같이 분류됩니다.

- `feat` : 새로운 기능
- `fix` : 버그 수정
- `docs` : 문서만 변경
- `style` : 코드의 의미에 영향을 주지 않는 변경 (공백, 포매팅, 누락된 세미콜론 등)
- `refactor` : 버그를 수정하거나 새 기능을 추가하지 않는 코드 변경
- `perf` : 성능 향상을 위한 코드 변경
- `test` : 누락된 테스트 추가 또는 기존 테스트 수정
- `chore` : 빌드 프로세스 또는 문서 생성과 같은 보조 도구 및 라이브러리 변경 사항 (코드 외적인 변경)

최종적으로 아래와 같은 형태가 됩니다.

```bash
feat(button): add a new variant

Add a new pink variant to the Button component.
```

팁: [Commitizen](https://github.com/commitizen/cz-cli)을 사용하면 컨벤션을 유지하면서 훨씬 쉽게 커밋 메시지를 작성할 수 있습니다.

## 개발하기

### 테스트

명확한 테스트 작성법은 아직 없습니다. 다만 경험으로 알게 된 몇 가지 교훈은 있습니다. 필수적이진 않지만, 다음과 같은 점들을 고려해서 테스트를 작성해 주시면 더 좋은 테스트를 작성할 수 있을 거로 생각합니다.

#### 단위 테스트

- 단위 테스트로는 컴포넌트의 스타일을 테스트하지 않기를 권장합니다. 되도록 컴포넌트의 동작에 대한 테스트를 작성해 주세요.
- 스냅숏 테스트는 테스트 커버리지를 올리는 것 외에 대체로 무의미했습니다.
- 테스트 케이스를 가능한 한 작은 단위로 분리하고, 중복이 있더라도 의도를 명확하게 표현해 주세요.

#### 스토리북

컴포넌트의 동작을 가장 명확하게 보여줄 수 있도록, 속성이 아무것도 지정돼 있지 않은 기본적인 컴포넌트의 스토리는 꼭 존재해야 합니다.

#### 참고 링크

아래 이슈들을 통해 계속해서 테스트 컨벤션을 논의할 예정입니다.

- [Unify the way writing story (#1331)](https://github.com/channel-io/bezier-react/issues/1331)
- [Unify the way writing unit tests (#1330)](https://github.com/channel-io/bezier-react/issues/1330)

### 코드 스타일

[코드 스타일](Code-style)을 참고해 주세요.

## 릴리즈

[릴리즈 가이드](Release)를 참고해 주세요.