TypeScript satisfies를 썼는데 값 타입이 기대와 다를 때
타입 검증은 통과하지만 이후 속성이 지나치게 좁게 추론되거나 readonly 기대와 달라집니다. 원인을 좁히고 최소 변경으로 해결한 뒤 재발 여부까지 확인하는 순서입니다.
짧은 요약
타입 검증은 통과하지만 이후 속성이 지나치게 좁게 추론되거나 readonly 기대와 달라집니다. 이 문제는 설정을 전부 초기화하기 전에 실제 실행 환경과 최초 오류를 확인해야 안전하게 해결할 수 있습니다. 핵심은 검증용 satisfies와 변수 타입 주석, as const의 역할을 구분해 필요한 추론 폭을 선택합니다.
증상과 환경
- 관련 기술: TypeScript
- 운영체제: Cross-platform
- 난이도: 보통
타입 검증은 통과하지만 이후 속성이 지나치게 좁게 추론되거나 readonly 기대와 달라집니다. 발생 시각, 오류 전문, 직전 배포 내용과 실제 도구 버전을 함께 기록합니다. 한 줄짜리 마지막 오류보다 그 앞에 나타난 최초 원인이 중요한 경우가 많습니다.
원인
satisfies는 표현식의 추론 타입을 선언 타입으로 바꾸지 않고 호환성만 검사합니다. 로컬 셸과 서비스·CI·컨테이너는 실행 계정과 환경변수가 다를 수 있으므로 한 환경의 결과만으로 결론 내리지 않습니다.
재현 예시
영향이 제한된 테스트 환경에서 정상 입력과 실패 입력을 하나씩 준비합니다. 변경은 한 번에 하나만 적용하고, 결과가 처음 달라지는 단계의 출력과 종료 코드를 비교합니다. 비밀번호와 토큰은 로그에서 제거합니다.
단계별 해결법
1. 오류 원문과 발생 시각, 실행 계정을 기록합니다.
2. 아래 진단 명령으로 버전과 현재 설정을 확인합니다.
3. 검증용 satisfies와 변수 타입 주석, as const의 역할을 구분해 필요한 추론 폭을 선택합니다.
4. 같은 입력으로 변경 전후 결과를 비교합니다.
5. 새 세션이나 깨끗한 배포 환경에서도 결과가 유지되는지 확인합니다.
코드·명령 예문
const config = { mode: "prod" } satisfies { mode: string };
npx tsc --noEmit예문의 <host>, <path>, <service>는 실제 값으로 바꿉니다. 먼저 조회 명령으로 대상을 확인한 다음 변경합니다.
확인법
문제를 만들었던 입력을 다시 실행해 정상 종료와 기대 결과를 확인합니다. 관련 테스트를 연속 두 번 수행하고 로그에 새 경고가 생기지 않았는지 살펴봅니다.
주의사항
권한 확대, 보안 검증 해제, 전체 캐시 삭제로 우회하지 않습니다. 운영 변경 전에는 원본 설정과 되돌릴 지점을 남기고 사용 중인 버전의 공식 문서에서 옵션 지원 여부를 확인합니다.
관련 이슈
- typescript-satisfies와 연관된 버전 차이
- 로컬과 배포 환경의 설정 불일치
- 이전 캐시 또는 실행 중인 프로세스의 영향