언어 감지 저장소에 확장자나 새 언어 추가하기

## 감지의 각 부분을 어떤 파일과 도구가 맡는지 파악하기 편집하기 전에 언어 감지의 각 부분을 어떤 파일과 도구가 관리하는지 확인하세요. - 이름, 확장자, 파일 이름, 언어 속성을 관리하는 언어 레지스트리 - 모호한 파일을 위한 휴리스틱 규칙과 그 구현 - 통계 분류기와 실제 샘플로 구성된 말뭉치 - 구문 강조 표시에 사용하는 문법 레지스트리 - 저장소에 포함된 문법 소스와 캐시된 라이선스 데이터 - 유지보수 스크립트, 테스트, 지속적 통합 진입점 이들을 서로 연동된 계약으로 취급하세요. 메타데이터를 변경할 때는 하나의 고립된 편집이 아니라 샘플, 휴리스틱, 생성 식별자, 문법 데이터, 테스트, 증거가 함께 필요할 수 있습니다. ## 저장소의 개발 컨테이너에서 준비하고 제공된 스크립트 사용하기 사용할 수 있다면 저장소에서 유지보수하는 개발 컨테이너나 호스팅 환경을 우선하세요. 이 환경은 선언된 언어 런타임, 패키지 도구, 컨테이너 런타임, 네이티브 라이브러리, 프로젝트의 모든 의존성을 제공해야 합니다. 로컬에서 작업할 때는 다음을 수행하세요. 1. 표준 초기 설정 명령을 실행하세요. 2. 저장소의 의존성 실행기를 통해 라이브러리나 명령줄 도구를 호출하세요. 3. 문서화된 유지보수 스크립트를 사용하고 그 효과를 수동으로 재현하지 마세요. 4. 인코딩 감지, 저장소 접근, 문법 작업에 필요한 네이티브 의존성이 있는지 확인하세요. 로컬에서 임시로 실행해 성공했다는 사실만으로 지원 환경에서도 검증을 통과한다고 판단하지 마세요. ## 알파벳 순서에 맞춰 확장자를 추가하고 실제 샘플 넣기 기존 언어에 파일 확장자를 추가할 때는 다음을 수행하세요. 1. 공식 언어 항목을 업데이트하세요. 2. 확장자 목록을 대소문자를 구분하는 필수 알파벳순으로 유지하고, 대문자를 소문자보다 앞에 두며, 주 확장자를 맨 앞에 두세요. 3. 담당 언어 아래에 실제 사용을 대표하는 샘플 파일을 추가하세요. 4. 다른 언어와 확장자를 공유한다면 최소 두 개의 샘플을 제공하고 모호성을 해소하는 휴리스틱을 추가하세요. 5. 메타데이터와 휴리스틱 동작에 대한 테스트를 추가하거나 업데이트하세요. 간단한 인사말 프로그램처럼 튜토리얼에서 흔히 쓰는 예를 분류기 증거로 사용하지 마세요. 샘플은 감지기가 인식해야 하는 실제 코드를 반영해야 합니다. ## 문법을 등록하고 스크립트로 만든 ID로 새 언어 추가하기 새 언어에는 레지스트리의 레이블만으로 충분하지 않습니다. 1. 언어 항목을 추가하되 생성 식별자는 설정하지 않은 상태로 두세요. 2. 표준 문법 도구를 통해 승인되고 호환되는 구문 강조 표시용 문법을 등록하세요. 3. 검증 가능한 원본 출처에서 실제 사용을 대표하는 샘플 파일을 추가하세요. 4. 식별자를 수동으로 할당하지 말고 식별자 생성 스크립트를 실행하세요. 5. 어떤 확장자든 여러 언어가 공유한다면 최소 두 개의 샘플을 제공하고 테스트된 모호성 해소 규칙을 추가하세요. 6. 메타데이터, 문법 등록, 분류, 생성된 변경 사항을 함께 검증하세요. 레지스트리 헤더의 지침, 필드 요구 사항, 대소문자를 구분하는 정렬 순서를 그대로 유지하세요. ## 확장자가 같은 언어를 구별하는 정규식 규칙을 테스트와 함께 작성하기 휴리스틱은 광범위한 오탐을 만들지 않으면서 실제 모호성을 해소해야 합니다. - 경쟁하는 언어를 구분하는 최소한의 특징적 증거를 일치시키세요. - 모든 패턴의 실행 시간이 입력 크기에 선형으로 비례하게 하세요. - 정규식 서비스 거부 공격에 취약한 구조를 피하세요. - 저장소에서 요구하는 정규식 엔진이 지원하는 구문만 사용하세요. - 양성 사례, 경쟁 언어 사례, 경계에 가까운 사례를 테스트하세요. - 휴리스틱이나 샘플 변경이 감지 동작을 바꿀 수 있다면 분류기 교차 검증을 실행하세요. 모든 휴리스틱에는 테스트가 있어야 합니다. 대상을 인식하더라도 관련 없는 파일까지 포착하는 규칙은 허용되지 않습니다. ## 생성된 파일은 손으로 고치지 말고 관리 명령으로 다시 만들기 생성된 레지스트리, 모듈 선언, 저장소에 포함된 문법 내용, 캐시된 문법 라이선스 파일을 수동으로 편집하지 마세요. 문법을 추가하거나 교체할 때는 해당 내용을 관리하는 유지보수 명령을 사용하고, 그 명령이 만든 모든 변경을 검토하세요. 문법을 승인하기 전에 다음을 확인하세요. - 프로젝트에서 사용하는 구문 강조 표시 형식과 호환되는지 확인하세요. - 라이선스가 승인 목록에 있는지 검증하세요. - 공식 원본 URL과 라이선스 기록을 보존하세요. - 지원되는 컨테이너 환경에서 문법 전용 검증을 실행하세요. 생성 결과가 잘못되었다면 결과를 직접 덧대지 말고 원본 입력이나 생성 워크플로를 수정하세요. ## 분류기 교차 검증과 전체 테스트 실행하기 가장 범위가 좁은 관련 검사부터 실행한 뒤 저장소에서 요구하는 전체 검증을 수행하세요. 1. 변경된 메타데이터와 정렬 순서를 검증하세요. 2. 새 샘플과 휴리스틱의 테스트를 실행하세요. 3. 감지 경계가 바뀔 수 있다면 분류기 교차 검증을 실행하세요. 4. 표준 의존성 실행기를 통해 전체 테스트 모음을 실행하세요. 5. 지속적 통합이 동일한 필수 단계를 통과하는지 확인하세요. 실패 원인을 검토해 오탐, 생성 파일의 불일치, 누락된 네이티브 의존성, 잘못된 문법 데이터, 관련 없는 언어에 대한 의도하지 않은 변경이 있는지 확인하세요. ## 제출 전에 사용량 증거와 샘플 라이선스 보여 주기 기여 요청을 제출하기 전에 다음을 수행하세요. - 제공된 요청 템플릿을 사용하고 관련 없는 섹션만 제거하세요. - 추가한 각 확장자에 대해 포크를 제외한 공개 검색 증거를 연결하세요. - 일반적인 확장자는 색인된 파일을 최소 2000개, 저장소마다 보통 한 번만 나타나는 이름은 200개 제시하세요. - 특정 사용자의 비중이 비정상적으로 높은 경우를 고려해 서로 다른 사용자와 저장소 조합에 합리적으로 분포하는지 확인하세요. - 각 샘플을 기여에 사용한 포크가 아니라 원본 출처에 연결하세요. - 각 샘플 코드의 라이선스를 개별적으로 명시하세요. - 모든 필수 테스트와 지속적 통합 검사를 통과하세요. - 변경 범위를 집중해서 유지하고 관련 없는 리팩터링을 섞지 마세요. 요구 사항을 하나라도 충족하지 못하면 요청을 제출하지 마세요. 어떤 증거, 라이선스, 테스트, 범위 조건이 부족한지와 먼저 완료해야 할 내용을 설명하세요.