이 프로젝트에 관심을 가져주셔서 감사합니다. 기여는 언제나 환영입니다! 🎉

본 프로젝트는 GitHub의 풀 리퀘스트(PR) 기반으로 기여를 관리하고 있습니다.
먼저 프로젝트를 포크하고 PR을 보내는 방법을 참고해 주세요.

1. Bun 설치하기
2. 프로젝트를 포크하고 PR을 보내는 방법을 참고해서 리포지토리를 자신의 계정에 포크하고, 클론합니다.
   1. 이 때 클론한 리포지토리를 업스트림 리포지토리와 동기화하는 설정을 함께 적용하면 기여에 용이합니다.
3. 터미널에서 아래 명령어를 실행합니다:

cd path/to/daleui
# 의존성 설치
bun install
# Storybook 실행 (디자인 시스템 기여 시)
bun run sb # or bun run storybook
# 마케팅 웹사이트 실행 (마케팅 웹사이트 기여 시)
bun run dev

• Figma: 디자인, 회고
• React: UI renderer
• Panda: Styling engine
• Ark UI: Headless UI components
• Storybook: 컴포넌트 시연, 문서화
• Chromatic: UI Preview/Tests/Reviews
• Vite: Bundler
• Vitest: Test Runner, Test Matcher
• TestingLibrary: UI Testing
• HappyDom: Testing DOM
• ESLint: Linter
• Prettier: Formatter
• GitHub Actions: CI/CD
• Bun: JS Runtime

• 무료 프로젝트 관리 기능인 깃허브 프로젝트를 통해 이슈(Jira 티켓과 같은 개념)를 관리해 주세요.
• 이슈를 생성할 때 유형(Type)을 반드시 선택해주시고, 프로젝트에 추가 후 우선순위(Priority)와 예상 소요 시간(Est)도 함께 넣어주세요.
• 이슈를 생성할 때 스프린트(Sprint)와 상태(Status)는 비워두어 일단 백로그(Backlog)에 두도록 해 주세요.
• 이슈는 팀 회의 때 Grooming, Triage, Planning 과정을 거친 후에 스프린트에 추가해 주세요.
• 긴급 이슈가 있거나 스프린트에 To Do 이슈가 소진되었을 때는 디스코드에서 소통 후에 현재 스프린트에 추가해주세요.
• 자율적인 협업과 자발적인 기여를 위해 특별한 사유가 없다면 이슈를 생성할 때 담당자를 설정하지 마세요.
• 이슈 상태는 스프린트에 추가되었을 때 부터 To Do로 설정해주세요.
• 작업을 시작하시면 이슈의 상태를 반드시 In Progress로 옮겨주세요. (많이 까먹는 부분이니 꼭 지켜 주세요.)
• 이슈가 연결된 Pull Request가 병합되면 이슈는 자동으로 Done 상태로 전환됩니다.
• 동시에 2개 이상 이슈를 할당하지 않도록 주의해주세요. WIP가 2보다 커지면 팀의 리뷰 부담이 커지니 참고해 주세요.
• 서브 이슈는 Spike 티켓에서 파생된 Action 티켓에 한해 사용해 주세요.
• 서브 이슈가 완료되지 않아도, 상위 Spike 티켓(Parent Issue)은 완료 처리해 주세요.
• 이슈가 스프린트 1회 이상 이관될 경우 spillover label을 추가해주세요.
• 이슈가 스프린트 2회 이상 이관될 경우 공론화하고 blocker 여부를 확인하여 해결 방향을 정리해주세요.

1. 프로젝트 보드에서 To Do 상태의 티켓을 선택하고 본인에게 할당해 주세요.
2. 프로젝트 설정

• 먼저 프로젝트 설정 가이드를 완료해 주세요.

3. 브랜치 생성

• main 브랜치에서 새로운 feature 브랜치를 생성해 주세요.
• 브랜치 이름에는 -, _ 외의 특수문자를 사용하지 마세요.
  참고 이슈

4. 기능 구현 및 커밋

• 브랜치 내에서 소스 코드를 수정하고 커밋해 주세요.
• 변경이 모두 완료되면 포크받은 리포지토리 브랜치를 푸시해 주세요.

5. 테스트 작성

• 기여한 코드가 정상적으로 동작하는지 확인하는 테스트 코드를 작성해 주세요.

6. PR 생성

• Pull Requests 페이지에서 새로운 PR을 생성해 주세요.

• PR 제목과 설명은 가급적 한국어로 작성해주세요. 이슈 제목과 일치하도록 작성해 주세요.

• PR이 등록된 이슈와 연관된다면, PR 생성 후 오른쪽 사이드바 Development 항목에서 해당 이슈를 선택해 연결해주세요.

  PR 이슈 연결 예시

7. PR 리뷰 및 병합

• 최소 한 명 이상의 관리자에게 PR 검토와 코멘트를 받아 주세요.
• 변경 요청이 있을 경우, 수정을 반영한 후 다시 푸시하고 리뷰를 요청해 주세요.
• 디자인 변경이 있을 경우, PR에 ui 태그를 달아서 Chromatic을 실행해 주세요.
• UI Review 체크에서 해당 디자인을 담당한 디자이너에게 리뷰를 요청해 주세요. (생성된 PR의 하단 Merge 부분에서 확인할 수 있음) [画像:image]

UI Review: 작업 내역을 디자인 담당자에게 확인 요청하는 작업

UI Tests: 코드 변경이 의도치 않은 UI 변화를 일으키지 않았는지, Chromatic 스냅샷을 하나씩 비교하며 개발자가 직접 확인하는 작업

• 최소 1개의 승인을 받은 후 main 브랜치에 병합해 주세요.
• 이후 릴리즈를 통해 기여한 내용이 배포됩니다.

• PR 병합을 하기 위해서는 최소 1명의 동료 개발자로부터 승인을 받아야 하지만, 품질 향상을 위해서 긴급 건이 아니라면 2개의 승인을 받는 것이 권장됩니다.
• [Proposed] "Resolve conversation" 버튼은 코드 검토자가 피드백이 본인이 의도한 대로 조치되었는지 확인하는 차원에서 누릅니다. 코드 작성자가 임의로 Resolved 표시할 시 오해가 생길 수 있습니다.

• 항상 의존성을 최신 상태로 유지하도록 Dependabot을 코드 저장소에 설정해놓았습니다.
• Dependabot이 올린 PR을 늦지 않게 검토 및 병합하고 새로운 버전이 일으키는 breaking changes를 대응하는 작업은 팀 개발자 모두의 공동 책임입니다.
• Dependabot이 올린 PR을 반드시 PR 코멘트를 통해서 Dependabot에게 원하시는 작업을 시켜주세요. 직접 수정하시면 Dependabot은 해당 PR을 더 이상 자동으로 관리해주지 않습니다.

main 브랜치에 품질 기준에 미달하는 코드가 유입이 되지 않도록 PR을 올리시면 자동으로 품질 검사가 진행되고 실패할 경우 병합이 불가능합니다. 각 품질 검사는 개발자가 로컬 환경에서 직접 진행하실 수도 있습니다.

Prettier를 통해서 일관적인 코드 포멧팅을 유지하고 있습니다. VSCode 사용자 분들은 Prettier 익스텐션을 쓰시면 코드를 작성하면서 자동으로 코드를 포멧팅할 수 있어서 편하니 추천드립니다.

Prettier options 는 기본 설정값으로 해주시길 바랍니다.

ESLint를 통해서 잠재적인 문제를 발견하고 모범 사례를 따르고 있습니다. 린팅 규칙을 위반하고 있는 코드가 있는지 확인하려면 다음 명령어를 실행합니다.

# 전체 검사
bun run lint
# 특정 파일 검사
bun run lint src/components/TextInput/TextInput.tsx

TypeScript를 통해서 정적 타입 검사를 하고 있습니다. 타입 오류가 있는지 확인하려면 다음 명령어를 실행합니다.

bunx tsc

flowchart TD
 MAIN[main 브랜치]
 RELEASE_PR["버전 bump &<br/>Release PR 생성<br/>(GitHub Action)"]
 TAG["태그 생성 &<br/>GitHub Release Draft 생성<br/>(GitHub Action)"]
 PUBLISH["npm publish 실행<br/>(GitHub Action)"]
 MAIN -->|"GitHub UI에서<br/>Release PR 실행<br/>(개발자)"| RELEASE_PR
 RELEASE_PR -->|"Release PR 리뷰 & 머지<br/>(개발자)"| TAG
 TAG -->|"GitHub Release 발행<br/>(개발자)"| PUBLISH

코드 스타일, 네이밍 규칙, PR 작성 규칙 등을 이해하기 위해 먼저 컨벤션 문서를 읽어주세요.