`noUncheckedIndexedAccess`: 인덱스 조회의 실패 드러내기

"arr[5]는 없을 수 있어. 타입도 그 사실을 말해야 해."

무엇을 더하는가

설정을 끄면 string[]의 arr[100]도 string으로 보이지만 실행 결과는 undefined일 수 있어. 설정을 켜면 모든 임의 인덱스 접근이 T | undefined가 되어 사용 전에 존재 여부를 처리해야 해.

왜 strict와 별도인가

기존 코드의 모든 배열 인덱스 접근에 영향을 주어 마이그레이션 비용이 크기 때문에 strict에 포함되지 않았어. 새 코드에서는 켜고, 레거시 코드에서는 영향 범위를 세어 계획적으로 옮겨.

객체 인덱스 시그니처도 같아

Record<string, User>에서 임의 키를 읽어도 키가 실제로 없을 수 있으므로 결과는 User | undefined가 돼. 배열과 사전 모두 런타임 현실을 같은 방식으로 반영해.

noUncheckedIndexedAccess는 인덱스 조회가 실패할 수 있다는 사실을 가장 정직하게 드러내는 설정이야. 사용 전에 좁히는 습관이 undefined 런타임 오류를 없애.

Code

Index 접근 — flag 와 함께와 없이·typescript

// noUncheckedIndexedAccess 없이 — 조용한 거짓말.
const arr: string[] = ['a', 'b'];
const x = arr[100];        // x: string — 근데 실제로 undefined
x.toUpperCase();           // runtime 에 크래시

// Flag 와 함께:
const arr2: string[] = ['a', 'b'];
const y = arr2[100];       // y: string | undefined
// y.toUpperCase();         // ❌ Object is possibly 'undefined'
if (y !== undefined) {
  y.toUpperCase();         // ✅ string 으로 narrow
}

// Object index signature 도 T | undefined 받음.
const map: Record<string, User> = { pippa: {} as User };
const u = map['pippa'];    // u: User | undefined
const u2 = map['missing']; // u2: User | undefined — 정확히

// Optional chaining 이 친구.
map['pippa']?.name;        // string | undefined

Exercise

문자열 배열의 범위 밖 인덱스를 읽어 사용해 봐. 옵션을 켰을 때 undefined 처리가 필요해지는지 보고 기존 프로젝트에서 영향을 받을 조회를 세어 봐.

Hint

배열과 사전의 인덱스 접근이 생각보다 많이 드러날 거야. 조회 직후 값의 존재를 확인하는 습관을 들이고, 고정된 자리는 튜플이나 닫힌 키 타입으로 표현해.

무엇을 더하는가

왜 strict와 별도인가

객체 인덱스 시그니처도 같아

Code

External links

Exercise

Progress

댓글 0