개발자 도구 · JSON 포맷터 및 유효성 검사기
CI가 수행되기 전에 손상된 package.json 수정: 오류 위치 읽기
· 그것이 중요한 이유
JSON 개발자 워크플로 검증
직접 편집한 package.json, composer.json 또는 launch.json은 일반적으로 CI에 저장한 지 오랜 후에 실패합니다. 이 게시물은 커밋하기 전에 유효성을 검사하고 오류 위치를 빠르게 읽는 방법을 보여줍니다.
하나의 쉼표를 배우기 위한 12분의 파이프라인
하나의 쉼표(손으로 해결한 병합 충돌, 녹색 편집기 및 빨간색 빌드)에 대해 알아보기 위한 12분의 파이프라인입니다. 매니페스트의 구문 분석 여부가 아니라 Git이 바이트를 기록하므로 저장소 체크아웃이 정상적으로 보일 수 있습니다. 그런 다음 CI는 종속성을 설치하고 손상된 파일에 도달한 후 테스트가 유용한 신호를 제공하기 전에 중지합니다.
이 도구는 엄격한 JSON 구문만 확인하고 최대 8,000,000 JavaScript 문자까지 문서를 허용합니다. package.json 및 작곡가.json은 적절한 엄격한 예입니다. tsconfig.json과 같은 파일은 주석 허용 파서를 사용할 수 있으므로 JSON로 주석을 거부한다고 해서 소유 도구가 해당 주석을 거부한다는 것을 증명하는 것은 아닙니다. 소비 프로그램이 실제로 선언하는 문법에 대해 유효성을 검사합니다.
가장 자주 중단되는 JSON 구성 파일
가장 자주 중단되는 JSON 구성 파일(package.json, 작곡가.json, launch.json 및 잠금 파일)과 주석을 허용하는 tsconfig.json에 별도의 관리가 필요한 이유. 사람이 편집한 매니페스트는 종속성 블록, 스크립트 및 중첩된 도구 설정 때문에 실패하는 경향이 있습니다. 생성된 잠금 파일은 다르게 실패합니다. 수동 충돌 해결로 인해 구분 기호가 손상되거나 구조 섹션이 중복될 수 있습니다.
JSON과 같은 확장자를 가진 모든 파일이 엄격한 JSON을 사용한다고 가정하지 마십시오. VS Code 설정 및 TypeScript 구성은 일반적으로 특수 파서를 통해 주석이나 후행 쉼표를 허용하지만 패키지 매니페스트는 일반적으로 허용하지 않습니다. 가능한 경우 패키지 관리자를 사용하여 생성된 잠금 파일의 유효성을 검사하십시오. 유효한 구문만으로는 해당 생성기가 기대하는 해시, 순서 규칙 또는 내부 일관성을 복원할 수 없기 때문입니다.
도구가 늦게 실패하는 이유 — 패키지 관리자와 컴파일러는 요청 시 구문 분석하므로 저장 시가 아닌 설치 또는 빌드 시 구문 오류가 나타납니다.
도구가 늦게 실패하는 이유 — 패키지 관리자와 컴파일러는 요청 시 구문 분석하므로 저장 시가 아닌 설치 또는 빌드 시 구문 오류가 나타납니다. 텍스트 편집기는 권한 있는 파서를 실행하지 않고 중괄호를 색칠할 수 있으며, 제한된 로컬 작업 중에 변경된 매니페스트를 읽지 못할 수 있습니다. CI는 깨끗한 환경에서 시작되며 캐시된 워크스테이션이 건너뛰는 설정 경로를 실행합니다.
결과적인 지연에는 대기열 시간, 체크아웃, 종속성 설정 및 관련 없는 예비 작업이 포함됩니다. 더 나쁜 것은 최종 메시지에서 명령 출력 뒤에 원래 줄을 숨기고 잘못된 패키지 파일 이름만 지정할 수 있다는 것입니다. 편집 직후 로컬 구문 분석은 해당 피드백 루프를 축소합니다. 또한 다른 조사가 필요한 이후 종속성 해결 또는 스키마 오류와 문법적 오류를 구분합니다.
압력 하에서 오류 위치 읽기
압력을 받고 있는 오류 위치 읽기 — 줄과 열, 이전 토큰, 잘못된 JSON을 생성하는 세 가지 병합 충돌 패턴. 표시된 문자는 계속이 불가능해진 위치이며 항상 실수가 시작된 위치는 아닙니다. 닫는 인용문은 이스케이프 처리되지 않은 이전 인용문을 노출할 수 있습니다. 중괄호는 다음 속성 바로 앞에 누락된 쉼표를 표시할 수 있습니다.
병합 후 일반 텍스트로 남아 있는 충돌 표시, 쉼표 없이 결합된 중복된 구성원 블록, 한쪽을 선택하는 동안 삭제된 구분 기호를 찾습니다. 보고된 위치 이전에 토큰을 검사하고 주변 컨테이너 경계를 계산합니다. 파서는 일반적으로 첫 번째 장애물만 보고하고 두 번째 독립적 충돌은 더 아래쪽에 남아 있을 수 있으므로 한 번 복구하고 유효성 검사를 다시 실행하고 원래 차이점을 보존합니다.
작업된 예: 잘못된 병합 후 package.json
작업된 예: 잘못된 병합 후 package.json — 중복된 종속성 블록, 누락된 쉼표, 유효성 검사기 보고서 및 수정 사항. `"scripts":{"test":"vitest"}` 다음에 바로 `"dependencies":{"vite":"7.3.6"}`이 따른다고 상상해 보세요. 두 번째 속성 이름은 수정 쉼표가 스크립트 개체 뒤에 속하더라도 파서가 개체에 구분 기호가 없음을 발견하는 곳입니다.
해당 쉼표를 삽입하고 형식을 지정하기 전에 다시 확인하세요. 병합으로 인해 두 개의 `dependencies` 키도 생성된 경우 구문상 중복된 이름이 허용되기 때문에 엄격한 구문 분석은 여전히 성공할 수 있지만 JavaScript 구문 분석은 이후 값만 유지합니다. 블록을 기계적으로 삭제하는 대신 두 분기를 비교하고 원하는 멤버를 결합합니다. 구문 복구와 의미론적 병합 해결은 연속적이고 별개의 작업입니다.
검증을 습관화하기
검증을 습관화하세요. 커밋하기 전에 붙여넣거나 계정이나 플러그인 없이 IDE 외부에서 편집한 JSON을 검증하세요. 가장 좋은 트리거는 행동입니다. 충돌 마커가 해결되거나 큰 블록이 이동되거나 구두점이 수동으로 입력될 때마다 파일을 준비하기 전에 소유 도구의 검사 또는 엄격한 파서를 실행합니다.
리포지토리는 사전 커밋 확인 및 매니페스트 범위의 CI 작업을 사용하여 동일한 규칙을 자동화할 수 있지만 자동화는 첫 번째 파서가 되기보다는 즉각적인 피드백을 보완해야 합니다. 차이점이 의미 있는 문자를 표시하도록 복구와 별도로 형식을 유지하세요. 생성된 파일의 경우 직접 편집한 출력을 정규화하는 대신 소스 매니페스트에서 다시 생성한 다음 생성기가 자체 불변성을 증명하도록 합니다.
여기서 다루지 않는 내용
여기서 다루지 않는 내용 — 잘못된 버전 범위 또는 알 수 없는 필드와 같은 의미론적 실수로 유효한 JSON이 사용자를 보호할 수 없습니다. 패키지 매니페스트는 존재하지 않는 스크립트의 이름을 지정하거나, 잘못된 섹션에 종속성을 배치하거나, 예기치 않게 해결되는 버전 표현식을 사용하는 동안 구문 분석할 수 있습니다. 중복 키는 이전 값을 자동으로 바꾸면서 문법 검사를 통과할 수도 있습니다.
패키지 관리자 유효성 검사, 스키마, 설치 테스트를 사용하고 해당 계층에 대해 검토합니다. 또한 이 검사는 잠금 파일이 해당 매니페스트와 일치하는지 또는 시작 구성이 설치된 디버거 이름을 지정하는지 입증하지 않습니다. 실제 형식이 JSONC 또는 다른 방언인 경우 단지 엄격한 JSON을 충족시키기 위해 지원되는 구문을 제거하는 대신 해당 파서를 사용하십시오. 문법은 완전한 구성 계약이 아닌 가장 초기의 관문입니다.
요약: 구문 확인에는 몇 초가 소요되고, 실패한 파이프라인에는 몇 분이 소요됩니다.
요점: 구문 확인에는 몇 초가 소요되고, 실패한 파이프라인에는 몇 분의 비용이 소요되며, 유효성 검사기의 정확한 보고서를 통해 수정 시간이 단축됩니다. 최종 편집된 바이트에서 실행하고 보고된 줄과 열에서 시작한 다음 이전 토큰에서 누락된 구분 기호 또는 구분 기호가 있는지 검사합니다. 이후의 오류는 처음에는 숨겨질 수 있으므로 모든 수정 후에는 다시 검증하십시오.
엄격한 구문을 통과하면 소비자에게 돌아갑니다. 허용되는 필드와 값을 이해하는 패키지 관리자, 컴파일러 또는 편집기별 유효성 검사를 실행합니다. 특히 병합 후에는 복구 차이를 좁게 유지하여 검토자가 종속성 결정과 구두점을 구별할 수 있도록 하세요. 이 시퀀스는 로컬에서 가장 저렴한 오류를 포착하고 전체 환경에서만 평가할 수 있는 동작을 위해 값비싼 파이프라인 시간을 예약합니다.