시크릿을 유출하거나 저장 데이터를 깨지 않고 여러 브라우저용 확장 기능 수정하기

## 먼저 영향받는 확장 기능 계층과 그 규칙 확인하기 코드를 변경하기 전에 영향을 받는 계층을 확인하세요. 해당 계층에는 백그라운드 로직, 사용자 인터페이스, 공유 유틸리티, 브라우저 선언, 빌드 도구, 테스트, 저장된 상태 업그레이드가 포함됩니다. 편집 전에 가장 가까운 계층별 지침을 읽으세요. 워크플로 자동화 파일에는 추가 연결 설정과 병합 대기열 규칙이 있는 경우가 많습니다. 저장소에서 관리하는 실행 환경과 패키지 관리자 래퍼를 사용하세요. 설정은 지정된 로컬 환경 파일에 보관하고 추적되는 소스에는 절대로 넣지 마세요. 새 구현 파일에는 현재 사용하는 타입 언어를 우선 적용하세요. 기존의 비타입 파일은 요청된 변경으로 변환이 타당해질 때까지 유지할 수 있습니다. 각 파일 종류에 지정된 포매터를 사용하세요. 코드 포매터는 타입 파일과 컴포넌트 파일을 담당하고, 구조화 데이터 포매터는 패키지와 설정 데이터를 담당합니다. 인계 전에 변경된 파일의 서식 지정, 정적 타입 검사, lint, 순환 의존성 검사를 실행하세요. 함수가 한 가지 책임에 집중하게 하고 조기 반환으로 중첩을 줄이세요. 추출로 소유 관계가 명확해지는 경우에만 반복 로직을 제거하고, 디버그 로그나 주석 처리된 코드를 남기지 마세요. ## 시크릿은 로컬에 두고 의존성 변경 후 정책 다시 만들기 API 자격 증명, 모니터링 엔드포인트, 테스트 비밀번호, 서명 자료를 로컬 시크릿으로 취급하세요. 문서화된 자리표시자를 제공하되 실제 값을 절대로 커밋하지 말고 진단 로그에 민감한 상태를 포함하지 마세요. 의존성을 추가, 업그레이드, 제거하는 모든 작업은 공급망 변경입니다. 전체 절차를 완료하세요. 1. 패키지 선언과 잠금 파일을 업데이트하세요. 2. 지원되는 명령으로 잠금 파일의 중복을 제거하세요. 3. 설치 스크립트 실행이 허용된 패키지의 허용 목록을 다시 계산하세요. 4. 의존성의 호스트 API 접근을 제한하는 권한 기능 정책을 다시 생성하세요. 5. 서드파티 귀속 정보를 다시 생성하세요. 6. 프로덕션 보안 정책을 활성화한 상태로 빌드하고 테스트하세요. 생성된 모든 정책과 귀속 정보 변경을 같은 리뷰에 포함하세요. 정책을 적용하지 않은 개발 빌드는 빠른 반복에 사용할 수 있지만 보호된 최종 빌드를 절대로 대신할 수 없습니다. 빌드를 통과시키기 위해 정책을 약화하지 말고 대상 플랫폼에서 플랫폼 종속 정책을 다시 생성하세요. ## 상태를 명확히 선언하고 도메인 동작으로 백그라운드 컨트롤러 설계하기 백그라운드 비즈니스 로직과 하위 시스템 간 메시지 기반 통신에 컨트롤러를 사용하세요. 저장되는 각 속성에 대해 익명인지, 진단 스냅샷이나 상태 로그에 안전하게 포함할 수 있는지, 영구적인지, 인터페이스에서 사용하는지를 선언하세요. 다음 상태 규칙을 따르세요. - 공유되는 변경 가능한 기본 객체가 아니라 새로운 객체를 반환하는 기본 상태 팩토리를 내보내세요. - 생성자 의존성은 위치 인수 대신 이름이 지정된 단일 옵션 객체로 받으세요. - 추가, 제거, 승인, 거부와 같은 도메인 작업을 모델링하고 범용 필드 설정자는 피하세요. - 필수 상태만 저장하고 개수, 플래그, 프로젝션은 내보낸 셀렉터를 통해 파생하세요. - 상태를 업데이트하기 전에 작업 입력을 검증하세요. - 타이머, 구독, 리스너, 메시지 채널의 수명 주기 정리를 구현한 다음 상위 컨트롤러의 정리에 위임하세요. 컨트롤러 소스, 타입, 같은 위치의 테스트, 등록, 영향을 받는 셀렉터를 동기화하세요. 상태 구조를 변경하려면 번호가 지정된 업그레이드 단계도 필요합니다. ## 코드를 담당 계층에 두고 연결된 파일도 함께 고치기 재사용 가능한 인터페이스 컴포넌트는 스타일, 타입, 테스트, 스토리, 문서, 공개 내보내기와 함께 배치하세요. 페이지 전용 컴포넌트는 페이지 계층에, 백그라운드 전용 헬퍼는 백그라운드 코드와 함께 배치하고, 실제로 공유되는 유틸리티, 상수, 타입은 공유 모듈에 배치하세요. 동작이 변경되면 직접 결합된 파일을 확인하세요. - 컨트롤러 변경에는 테스트, 타입, 등록, 상태 업그레이드가 필요할 수 있습니다. - 컴포넌트 속성 변경에는 테스트, 스토리, 스타일, 문서, 내보내기가 필요할 수 있습니다. - 전역 상태 변경에는 셀렉터와 이를 사용하는 컴포넌트가 필요할 수 있습니다. - 빌드 또는 브라우저 선언 변경에는 대상별 픽스처와 엔드투엔드 범위가 필요할 수 있습니다. 소유자를 선택하지 않기 위해 공유 로직을 복사하지 마세요. 가장 좁은 공통 계층으로 옮기고 필요하면 의존성 주입을 사용하며, 예외 목록 확대를 받아들이지 말고 순환 가져오기를 해결하세요. ## 브라우저 대상과 기능 플래그별로 따로 빌드하고 테스트하기 지원되는 각 브라우저 선언 생성 방식에 대해 별도의 빌드 및 테스트 경로를 유지하세요. 지속형 백그라운드 페이지와 서비스 워커의 차이, 권한 모델, 네임스페이스 가용성 등을 고려하세요. 공유 코드에서는 크로스 브라우저 API 추상화를 사용하세요. 피할 수 없는 대상별 차이는 기능 곳곳에 조건을 흩뿌리지 말고 작은 호환성 계층에 격리하세요. 기능 플래그는 명시적인 빌드 입력이어야 합니다. - 재현 가능한 개발에는 문서화된 로컬 설정을 사용하세요. - 격리된 실험에는 단일 명령 환경 재정의를 사용하세요. - 원격 플래그 테스트 시나리오에만 로컬 선언 재정의를 사용하세요. - 실제 배포할 대상과 플래그 조합을 그대로 빌드하고 테스트하세요. 사용자가 브라우저를 지정하지 않으면 프로젝트에 문서화된 기본 대상을 사용하세요. 요청에서 대상을 지정하면 다른 빌드에서 호환성을 추정하지 말고 해당 개발, 프로덕션, 엔드투엔드 명령을 선택하세요. ## 인터페이스 컴포넌트를 만들고 측정한 뒤에만 최적화하기 함수형 컴포넌트와 훅을 사용하고 경계에서 속성을 구조 분해하세요. 로컬 전용 상태는 로컬에 유지하고, 기능 간 데이터에만 공유 상태 계층을 사용하세요. 렌더링의 정확성과 성능을 유지하려면 다음 규칙을 따르세요. - 동적 목록의 키로 배열 위치가 아닌 안정적인 도메인 식별자를 사용하세요. - 파생된 표시 값은 이펙트로 상태에 복사하지 말고 렌더링 중에 계산하세요. - 비용이 큰 정렬, 필터링, 집계는 반복 작업의 부담이 실질적인 경우에만 메모이제이션을 적용하세요. - 참조 변경으로 다시 렌더링되는 경우 메모이제이션된 자식에게 전달하는 콜백을 안정화하세요. - 실제로 정적인 객체와 스타일은 컴포넌트 외부에 정의하세요. - 대규모 목록은 렌더링 비용을 측정한 후 가상화를 고려하세요. 입력이 불변이면 정렬 전에 복사하세요. 자주 렌더링되거나 계산 비용이 큰 컴포넌트를 먼저 프로파일링하세요. 근거 없이 단순하고 드물게 렌더링되는 컴포넌트에 메모이제이션을 추가하지 마세요. ## 실패하는 테스트로 버그를 재현한 뒤 고치고 다시 테스트하기 버그의 경우 먼저 실패를 재현하는 범위가 좁은 테스트를 추가하고 실패 상태로 실행하세요. 최소한의 수정만 구현한 뒤 성공 상태로 실행하고 직접 관련된 범위를 테스트하세요. 단위 테스트는 소스와 같은 위치에 두고 비공개 메서드가 아닌 공개 인터페이스를 통해 동작을 테스트하세요. 하위 시스템 간 경계에는 통합 테스트를 사용하세요. 실제 브라우저 워크플로에는 엔드투엔드 테스트를 사용하고 전용 테스트 산출물을 먼저 빌드하세요. 반복 중에는 더 빠른 미보호 빌드를 허용할 수 있지만, 최종 검증에는 프로덕션 보안 정책과 요청된 브라우저 대상을 사용해야 합니다. 시각적 검증을 명시적으로 요청한 경우: 1. 실제 확장 기능 테스트 환경을 시작하세요. 2. 작업하기 전에 현재 화면을 확인하세요. 3. 브라우저 컨트롤로 사용자 흐름을 진행하세요. 4. 증거로 스크린샷이나 최종 화면 설명을 기록하세요. 5. 실패한 경우에도 테스트 세션을 정리하세요. 필요한 시각적 도구를 사용할 수 없으면 해당 제한을 보고하고 코드 검사만으로 시각적 검증을 했다고 주장하지 마세요. 스냅샷 변경은 수락하기 전에 검토하고, 동작 변경이 의도된 경우에만 스냅샷을 업데이트하세요. ## 저장 데이터 구조가 바뀌면 번호 붙은 업그레이드 작성하기 영구 상태 구조가 변경될 때마다 번호가 지정된 업그레이드를 만드세요. 순서와 등록의 일관성을 유지하도록 저장소 도구를 통해 생성하세요. 업그레이드는 다음 요건을 충족해야 합니다. - 오래되거나 불완전하거나 부분적으로 손상된 입력을 적절하게 받아들이세요. - 호출자의 값을 변경하지 말고 입력을 복제하여 새 상태 객체를 반환하세요. - 자신이 담당하는 버전 범위와 속성만 변환하세요. - 대상 버전을 명시적으로 기록하세요. - 관련 없는 사용자 데이터를 보존하세요. 대표적인 이전 상태, 누락된 필드, 잘못된 선택적 값, 멱등성 기대치, 정확한 새 출력을 테스트하세요. 업그레이드 테스트와 업그레이드된 상태를 사용하는 컨트롤러 또는 기능 테스트를 모두 실행하세요. ## 오류를 종류별로 나누고 검사를 끄지 않고 고치기 환경을 변경하기 전에 처음으로 조치할 수 있는 오류를 읽으세요. 서식, 타입, 의존성, 권한 기능 정책, 브라우저 빌드, 테스트 데이터, 오래된 산출물, 포트, 순환 가져오기 실패로 분류한 다음 해당 분류에 가장 한정된 진단을 실행하세요. 이전에 성공하던 테스트가 변경 후 실패하면 구현이 퇴행했는지, 예상 동작이 의도적으로 변경되었는지 판단하세요. 후자인 경우에만 테스트를 업데이트하고 동작상 이유를 문서화하세요. 엔드투엔드 실패에서는 정확한 최신 테스트 빌드가 있는지 확인하고 디버그 출력을 사용하며, 실제로 검사하는 동안에만 브라우저를 실행 상태로 두세요. 정책 실패에서는 선언된 의존성과 호스트 접근을 기준으로 정책을 다시 생성하고 적용을 영구적으로 비활성화하지 마세요. 캐시, 빌드 산출물, 설치된 패키지, 브라우저 데이터, 스냅샷은 정확한 대상을 확인하고 안전하게 다시 생성할 수 있음을 확인한 뒤에만 제거하세요. 문제 해결의 첫 단계로 광범위한 정리를 사용하지 마세요. ## Git 커밋, 푸시, 리뷰 요청은 요청받을 때만 하기 저장소 설정을 변경하거나 파괴적인 버전 관리 명령을 실행하지 마세요. 사용자가 해당 작업을 구체적으로 명시해 요청하지 않았다면 스테이징, 커밋, 푸시, 리뷰 요청 생성을 수행하지 마세요. 승인된 경우: - 요청된 변경에 속하는 파일만 스테이징하세요. - 커밋 전에 변경된 범위를 서식 지정하고 테스트하세요. - 저장소의 구조화된 커밋 규칙을 사용하세요. - 푸시가 요청된 경우에만 푸시하세요. - 사용자가 준비 완료 상태를 명시적으로 요청하지 않았다면 초안 리뷰 요청을 만드세요. - 리뷰 템플릿을 따르고 해당하지 않는 섹션을 완전히 숨기세요. 수동 테스트 섹션에는 자동화된 lint나 테스트 명령이 아니라 사람이 수행하는 작업과 눈에 보이는 결과를 설명해야 합니다. 인터페이스의 시각적 변경에는 변경 전후 증거를 포함하고, 명확하지 않은 결정을 설명하며, 관련 작업을 연결하고, 필요한 경우 사용자 대상 변경 메모를 식별하세요. 리뷰 중에는 검토된 기록을 다시 작성하지 말고 피드백에 답변한 뒤 후속 커밋을 추가하세요. 병합 전에는 해결된 대화, 승인, 성공한 자동화, 저장소에서 요구하는 squash 제목을 필수로 확인하세요. 마지막으로 변경 규모에 맞는 체크리스트를 확인하세요. 변경 파일 서식 지정, 타입, 순환 의존성, 범위를 좁힌 테스트, 영향을 받는 빌드, 관련 파일, 문서, 의존성이 변경된 경우의 프로덕션 권한 기능 정책, 요청된 경우의 실제 시각적 증거를 포함합니다.