`exactOptionalPropertyTypes`

"`{ a?: string }` 가 'a 빠질 수 있어' 의미. 'a 가 명시 undefined 일 수 있어' 의미 아냐. Flag 가 차이 강제."

뭐 바꿔

Flag 없이: { a?: string } 가 `{}` 와 `{ a: undefined }` 둘 다 받음. 동등 취급. Flag 와 함께: 첫째만 받음; `{ a: undefined }` 가 이제 타입 에러 — 타입을 `{ a?: string | undefined }` 로 안 쓰면.

차이가 2 real-world 시나리오에 중요: serialization (JSON.stringify 가 undefined key 떨굼, 근데 빠진 key 와 undefined key 가 round-trip 다름) 과 property merging (Object.assign 이 `{a: undefined}` 를 'a 를 undefined 로 설정' 으로, 'a 그대로 둠' 아냐).

Migration 비용

대부분 codebase 가 '여기 값 없음' 의미로 `{a: undefined}` 쓴 자리 많음. 이 flag 켜면 다 노출. Fix 가 보통:

Property 설정 그만: 완전히 omit.
타입이 명시 undefined 허용: `{ a?: string | undefined }`.
코드 나머지에서 빠짐과 undefined 혼동 그만.

Flag 가 가장 좋은 방식으로 pedantic: '부재' 와 '있지만-undefined' 가 같은지 명확히 하게 강제. 대부분 같아야 — 그리고 flag 의 체크가 확인. 다른 case 가 정확히 flag 가 찾기 도와주는 버그.

Code

exactOptionalPropertyTypes 없이와 함께·typescript

interface Config {
  host?: string;
}

// exactOptionalPropertyTypes 없이:
const a: Config = {};                     // ✅
const b: Config = { host: undefined };     // ✅ 받음

// Flag 와 함께:
const c: Config = {};                     // ✅
const d: Config = { host: undefined };     // ❌ — host omit 되거나 string 이어야

// 둘 다 허용하려면 명시 선언:
interface Config2 {
  host?: string | undefined;
}
const e: Config2 = { host: undefined };    // ✅

Exercise

작은 codebase 가져와. exactOptionalPropertyTypes 켜. 에러 세. 각각에 대해 property omit 할지 명시 undefined 허용하도록 타입 확장할지 결정. 어느 case 가 더 흔한지 알아채 — codebase 의 습관에 대해 뭐 말해주는지.

Hint

대부분 프로젝트가 mix: 명시 undefined 가 역사적으로 '값 없음' 의미로 쓰임, 근데 omission 이 더 깨끗한 선택. Flag 의 가치가 강제 inventory.

뭐 바꿔

Migration 비용

Code

External links

Exercise

Progress

댓글 0