UI 컴포넌트 라이브러리를 고치고, 망가진 곳이 없는지 확인하기

## 저장소가 정한 패키지 관리 도구로 루트 폴더에서 명령 실행하기 저장소에 선언된 패키지 관리자와 워크스페이스 명령 형식만 사용하세요. 패키지 디렉터리로 이동해 다른 도구를 호출하지 말고, 루트에서 관리자의 워크스페이스 필터를 통해 패키지 범위 작업을 실행하세요. 필요한 경우에만 종속성을 설치하세요. 반복 작업 중에는 범위가 가장 좁은 패키지 빌드, 테스트, 린트 또는 타입 검사 명령을 우선 사용하고, 저장소 전체 빌드는 통합 또는 릴리스 검증을 위해 남겨 두세요. 문서 개발, 패키지 빌드, 문서 빌드, 단위 테스트, 브라우저 테스트, 엔드투엔드 테스트, 시각적 회귀 테스트, 포맷팅, 린트, 타입 검사를 서로 구분된 워크플로로 유지하세요. ## 새 컴포넌트는 실험 영역에 두고, 내부 패키지는 밖에 드러내지 않기 라이브러리를 핵심 컴포넌트, 스타일링 시스템, 실험적 컴포넌트, 아이콘 또는 자산, 공유 유틸리티, 스타일링 엔진 추상화, 미공개 내부 패키지로 구분하세요. 어떤 패키지가 공개용이고 어떤 패키지가 워크스페이스 지원용으로만 존재하는지에 관한 경계를 준수하세요. 새롭거나 불안정한 컴포넌트는 안정 패키지로 승격하기 전에 지정된 실험 영역에 도입하세요. 공유 스타일과 테마 동작을 컴포넌트마다 중복하지 말고 스타일링 계층에 유지하세요. 내부 패키지를 공개 진입점을 통해 노출하거나, 구현별 가정을 사용해 설정된 스타일링 엔진 추상화를 우회하지 마세요. ## 컴포넌트 파일을 정리하고, 필요한 것만 가져오기 구현, 선언, 테스트, 스타일 클래스, 공개 내보내기에 관해 저장소의 컴포넌트 파일 구성을 따르세요. API 문서, 테스트, 트리 셰이킹을 예측 가능한 상태로 유지할 수 있도록 각 책임을 해당 책임을 소유한 파일에 두세요. 공개 컴포넌트 속성에는 저장소가 요구하는 선언 형식을 사용하고, 컴포넌트 모듈에서 일관된 이름의 속성 인터페이스를 내보내세요. 경로 별칭과 공개 내보내기 규칙을 유지하세요. 광범위한 배럴 가져오기로 인해 전체 패키지가 번들에 포함되는 경우에는 워크스페이스 내부에서 범위가 좁은 단일 단계 패키지 가져오기를 사용하세요. 가져오기 형태를 스타일 선호가 아니라 성능 및 패키징 계약으로 취급하세요. ## 무슨 일이 생겼고 어떻게 고치는지 알려 주는 오류 메시지 쓰기 공개 패키지에서 발생시키는 모든 오류에는 무슨 일이 일어났는지, 그것이 왜 중요한지, 호출자가 이를 해결하기 위해 무엇을 할 수 있는지를 명시해야 합니다. 필수 라이브러리 접두사와 읽기 쉬운 메시지 구성 방식을 사용하고, 유지 관리되는 지침이 있으면 문서 링크를 제공하세요. 지원되는 오류 생성자에 저장소의 오류 축소 마커를 적용하여, 프로덕션 번들에서는 긴 메시지를 안정적인 코드로 바꿀 수 있고 개발 환경에서는 계속 이해하기 쉬운 메시지를 제공하도록 하세요. 공개 오류를 추가하거나 변경한 뒤에는 오류 코드 카탈로그를 다시 생성하세요. 의미 체계와 인수 개수가 변경되지 않았다면 같은 오류 계약에 새 코드를 만들지 말고 기존 카탈로그 항목을 업데이트하세요. ## 사용자가 실제로 클릭하고 입력하는 방식으로 컴포넌트 테스트하기 컴포넌트 테스트가 지원 환경과 일치하도록 저장소의 공유 렌더러와 어설션 유틸리티를 사용하세요. 저수준 이벤트 디스패치나 직접적인 속성 변경보다 접근 가능한 쿼리와 완전한 사용자 상호작용을 우선하세요. 구성된 매처를 사용해 관찰 가능한 동작, 상태 전환, 경고, 오류를 테스트하세요. 단위 테스트는 초점을 좁게 유지하고 반복 작업 중에는 이름 필터를 사용하되, 필터링된 실행의 통과를 전체 범위의 통과로 오인하지 마세요. 테스트에 레이아웃, 브라우저 API 또는 시뮬레이션된 DOM에서 사용할 수 없는 렌더링 동작이 필요하면 지원되는 실제 브라우저 환경으로 테스트를 제한하고 테스트 조건에 그 이유를 기록하세요. ## 스크린샷 확인을 꺼도 접근성 확인은 끄지 않기 저장소가 해당 세션을 공유하는 경우, 설정된 브라우저 회귀 루프 안에서 접근성 분석을 실행하세요. 스크린샷과 접근성 어설션을 서로 독립된 제어로 취급하세요. 데모에서 하나를 비활성화하더라도 다른 하나가 암묵적으로 비활성화되어서는 안 됩니다. 접근성 규칙의 적용 범위를 명시적으로 유지하세요. 데모 및 규칙별로 통과, 실패, 미완료 결과를 기록하고, 적용 가능한 접근성 표준 태그를 포함하며, 범위가 좁고 정당한 예외가 구성된 경우가 아니라면 필수 어설션을 유지하세요. 통합 회귀 하네스가 이미 탐색, 렌더링, 스크린샷, 접근성 분석을 담당하는 경우 별도의 브라우저 워크플로를 시작하지 마세요. ## 데모 하나를 뺀 규칙이 다른 데모까지 빼지 않도록 예외 규칙 순서 정하기 회귀 구성을 안정적인 데모 식별자와 대조하세요. 규칙이 상속 없이 마지막 일치 우선의 우선순위를 사용할 때에는 범위가 좁은 재정의를 광범위한 규칙 뒤에 배치하고, 재정의가 유지하려는 모든 필드를 다시 명시하세요. 개별 데모에는 범위가 좁은 패턴을 사용하고, 더 넓은 패턴은 완전한 컴포넌트 그룹에만 사용하세요. 단일 데모를 비활성화하는 규칙이 실수로 같은 그룹의 다른 데모까지 비활성화하거나 오래된 예외 필드를 상속해서는 안 됩니다. 규칙을 변경한 뒤에는 구조화된 접근성 및 시각적 출력을 다시 생성하세요. 지속적 통합은 한 번도 실행되지 않은 구성을 묵인하지 말고 오래된 생성 보고서를 거부해야 합니다. ## 작업 중에는 관련된 것만 테스트하고, 올리기 전에 전체 테스트 실행하기 일치하지 않는 테스트가 브라우저 탐색을 수행하거나 관련 없는 출력을 다시 작성하지 않도록 테스트 러너의 이름 필터로 로컬 회귀 실행 범위를 제한하세요. 필터가 테스트 이름에 포함된 경로나 데모 식별자와 일치하는지 확인하세요. 필터링된 실행은 일치하는 컴포넌트 보고서만 새로 고친다는 점을 이해하세요. 변경 사항을 푸시하기 전에 필터 없이 회귀 명령을 실행하여 모든 보고서, 스크린샷, 접근성 결과를 최신 상태로 만드세요. 저장소 워크플로에서 요구하는 경우 회귀 서버와 러너를 별도 프로세스로 유지하고, 인수 전달을 위해 문서화된 패키지 관리자 구문을 그대로 사용하세요. ## 컴포넌트를 고친 뒤 API 문서와 데모 다시 만들기 컴포넌트 속성이나 타입 선언을 변경한 뒤에는 속성 추출 생성기와 API 문서 생성기를 실행하세요. 그 결과로 생긴 공개 API 차이를 소스 변경 사항과 함께 검토하세요. 지정된 타입 적용 데모를 정본으로 작성하고, 지원되는 포맷터나 변환기를 통해 다른 언어 변형을 생성하세요. 생성된 데모 변형을 유일한 수정 방법으로 삼아 직접 편집하지 마세요. 데모나 Markdown을 변경하면 그에 해당하는 데모 생성, 문서 빌드, 문장 스타일, 문법 검사를 실행하세요. 특수한 통합 지침은 독립적인 로컬 지침 모듈에 보관하고, 스타일링, 테마 설정, 렌더링 또는 프레임워크 통합 작업에는 관련 모듈을 불러오세요. ## 변경에 필요한 확인을 하고, 못 한 확인은 알리기 검토하기 전에 변경된 파일을 포맷하고 린트와 타입 검사를 실행하며, 초점을 좁힌 단위 테스트를 수행하세요. 그런 다음 영향을 받는 동작에 따라 실제 브라우저, 엔드투엔드, 시각적 검사, 접근성, API 문서 또는 문장 검사의 범위로 확대하세요. 소스가 변경된 경우 생성된 오류 코드, API 참조, 데모 변형, 스크린샷, 접근성 보고서를 검증하세요. 차단되었거나 실행하지 않은 게이트가 있으면 부분 검증을 완료된 검증으로 제시하지 말고 이를 보고하세요. 검토 범위를 컴포넌트에 집중하고 저장소가 요구하는 변경 제목 형식을 사용하세요: 안정적인 컴포넌트 또는 문서 범위 뒤에 명령형 설명을 붙이세요.