-
Notifications
You must be signed in to change notification settings - Fork 48
Contribute
이 문서는 Bezier React에 기여하는 개발자를 위한 가이드를 제공합니다.
우리는 모든 기여자가 기여자 행동 강령 규약을 준수하길 기대합니다.
이 프로젝트는 채널코퍼레이션에서 관리하고 있지만, 오픈 소스 라이선스 하에 공개되어 있습니다. 이는 외부 기여자들도 프로젝트에 참여할 수 있음을 의미합니다. 우리는 외부인의 기여를 환영합니다! 실제로 다양한 관점과 경험은 프로젝트를 더욱 성장시키는 데 큰 도움이 됩니다.
이 프로젝트는 Apache 2.0 라이선스를 따릅니다. 이 라이선스 하에, 어떠한 형태로든 코드를 사용, 수정, 배포할 수 있습니다.
우리는 사용자에게 안정적이고 예측할 수 있는 업데이트를 제공하기 위해 유의적 버전 명세(SemVer)를 따르고 있습니다. 명세에 따라 버전은 다음과 같은 규칙을 따라 증가합니다.
주.부.수 (ex: 1.0.0)- 수(패치) 버전은 기존 버전과 호환되는 버그 수정에 따라 증가합니다.
- 부(마이너) 버전은 기존 버전과 호환되는 새로운 기능 추가에 따라 증가합니다.
- 주(메이저) 버전은 기존 버전과 호환되지 않는 변경 사항이 있을 때 증가합니다.
아래는 어떤 버전이 어떤 경우에 증가하는지에 대한 대표적인 예시입니다.
- 컴포넌트 제거
- 컴포넌트의 속성 제거
- 기존 속성의 호환되지 않는 타입 변경
- 공개된 함수 및 믹스인의 호환되지 않는 변경
- 새로운 컴포넌트 추가
- 컴포넌트에 새로운 속성 추가
- 기존 속성의 타입 확장
- 컴포넌트, 속성, 공개된 함수, 믹스인 등의 지원 중지(deprecated) 처리
- 컴포넌트가 생성하는 HTML의 변경(클래스 추가, 제거, 이름 변경 등)
- 공개된 API에 영향을 주지 않는 변경
- 비공개된 함수 및 믹스인의 호환되지 않는 변경
호환되지 않는 변경은 필수 불가결합니다. 하지만 호환되지 않는 변경 사항이 있을 때마다 주 버전을 증가시키는 건 버전 관리에 있어서 좋지 않습니다. 의존하는 프로젝트의 업그레이드 비용이 너무 크기 때문입니다.
우리는 먼저 지원 중지 처리를 하고, 다음 주 버전에서 실제 변경 사항을 적용하는 방식을 사용하고 있습니다. 호환되지 않는 변경 사항을 처리하고, 지원 중지하는 과정에 대한 자세한 가이드는 지원 중지 가이드라인을 참고해 주세요.
안정화 단계가 아닌 컴포넌트들에 대해서는 유의적 버전 명세를 적용하지 않습니다. 즉, 실험적인 컴포넌트에 호환되지 않는 변경이 일어나더라도 주 버전을 올리는 것이 아닌 수(패치) 버전을 올리는 것을 원칙으로 합니다. 이 컴포넌트들은 컴포넌트의 이름에 Alpha 접두사를 가지고 있습니다. bezier-react의 주 버전을 올리게 될 때 해당 컴포넌트의 Alpha 접두사를 제거하게 됩니다.
기본 브랜치(main) 하나만 운영합니다. 이 브랜치에서 안정된 버전 배포가 이루어집니다. 이 브랜치에서 새로운 브랜치를 생성하고, PR을 보내는 방식으로 개발이 진행됩니다. 필요한 경우 alpha 나 next 같은 개발 브랜치가 추가되어 개발이 진행될 수 있습니다.
Squash and merge 전략을 사용하여 진행합니다. 각 PR이 하나의 커밋으로 표현되기 때문에, 커밋 히스토리가 깔끔해지는 장점이 있습니다. 추가적인 개발 브랜치를 운용하는 경우, 기본 브랜치로부터 주기적인 리베이스가 이루어질 수 있습니다.
이슈를 통해 메인테이너 및 다른 기여자들과 의견을 공유할 수 있습니다. 개발하기 이전에 먼저 이슈를 검색해 주세요. 이미 해당 이슈가 존재한다면, 해당 이슈에서 논의를 진행해 주세요. 존재하지 않는다면, 새로운 이슈를 생성해 주세요.
템플릿을 통해 이슈를 제출해 주세요.
템플릿을 통해 이슈를 제출해 주세요.
PR이 생성되면 1. 프로젝트 메인테이너와 2. 해당 변경 사항에 영향을 받는 코드의 코드 오너가 코드 리뷰를 진행합니다. 모든 테스트를 통과하고, 리뷰어의 승인을 받으면 변경 사항을 머지할 수 있습니다.
PR을 제출하기 전에 꼭 다음 사항을 확인해 주세요.
- 저장소를 포크한 후
main브랜치에서 브랜치를 생성합니다. - 루트에서
yarn을 실행하여 패키지를 설치합니다. - 테스트가 필요한 코드를 추가했다면, 테스트를 추가합니다.
-
yarn test명령어를 통해 테스트 스위트가 통과하는지 확인합니다. -
yarn lint명령어를 통해 코드가 린트 규칙에 맞는지 확인합니다. -
yarn typecheck명령어를 통해 타입 검사를 진행합니다. -
yarn dev명령어를 통해 스토리북을 실행하고, 다양한 환경에서 테스트를 진행합니다. - 릴리즈가 필요한 변경 사항일 경우,
yarn changeset명령어를 통해 changeset을 생성합니다. 더 알아보기 - 포크한 저장소에 푸시합니다.
- 포크한 저장소에서 원본 저장소로 PR을 제출합니다.
위에 해당하는 내용들은 PR 템플릿에 셀프 체크리스트로 일부 포함되어 있습니다. PR을 오픈하기 전에 모든 체크리스트를 확인하고 체크해주세요.
yarn changeset 을 통해 작성하는 내용은 다음 릴리즈의 릴리즈 노트 및 소스 내부의 체인지로그에 포함됩니다. 아직 명확히 정해진 형식은 없지만, 다음과 같은 점들을 고려해서 작성해 주세요.
- 유의적 버전 명세에 따라 적절한 다음 버전을 선택합니다.
- 변경 사항에 대한 설명은 영문으로 작성합니다.
- 영문 대소문자를 지켜주세요.
- 자세한 구현을 모르는 사람도 이해할 수 있도록 작성해 주세요. (ex:
Fix a bug->Fix a bug that caused the button to be rendered incorrectly when the screen size is less than 320px)
라이브러리 사용자에게 영향을 주지 않는 변경 사항의 경우 체인지로그에 포함하지 않습니다. 개발 단계의 의존성 업데이트나, 린트 규칙 변경 등이 해당할 수 있습니다.
AngularJS의 커밋 메시지 컨벤션을 따라서 영문으로 작성합니다. 커밋 메시지의 타입은 다음과 같이 분류됩니다.
-
feat: 새로운 기능 -
fix: 버그 수정 -
docs: 문서만 변경 -
style: 코드의 의미에 영향을 주지 않는 변경 (공백, 포매팅, 누락된 세미콜론 등) -
refactor: 버그를 수정하거나 새 기능을 추가하지 않는 코드 변경 -
perf: 성능 향상을 위한 코드 변경 -
test: 누락된 테스트 추가 또는 기존 테스트 수정 -
chore: 빌드 프로세스 또는 문서 생성과 같은 보조 도구 및 라이브러리 변경 사항 (코드 외적인 변경)
최종적으로 아래와 같은 형태가 됩니다.
feat(button): add a new variant
Add a new pink variant to the Button component.팁: Commitizen을 사용하면 컨벤션을 유지하면서 훨씬 쉽게 커밋 메시지를 작성할 수 있습니다.
명확한 테스트 작성법은 아직 없습니다. 다만 경험으로 알게 된 몇 가지 교훈은 있습니다. 필수적이진 않지만, 다음과 같은 점들을 고려해서 테스트를 작성해 주시면 더 좋은 테스트를 작성할 수 있을 거로 생각합니다.
- 단위 테스트로는 컴포넌트의 스타일을 테스트하지 않기를 권장합니다. 되도록 컴포넌트의 동작에 대한 테스트를 작성해 주세요.
- 스냅숏 테스트는 테스트 커버리지를 올리는 것 외에 대체로 무의미했습니다.
- 테스트 케이스를 가능한 한 작은 단위로 분리하고, 중복이 있더라도 의도를 명확하게 표현해 주세요.
컴포넌트의 동작을 가장 명확하게 보여줄 수 있도록, 속성이 아무것도 지정돼 있지 않은 기본적인 컴포넌트의 스토리는 꼭 존재해야 합니다.
아래 이슈들을 통해 계속해서 테스트 컨벤션을 논의할 예정입니다.
코드 스타일을 참고해 주세요.
릴리즈 가이드를 참고해 주세요.