설정 객체, 타입 표기냐 satisfies냐

선택 속성에서도 차이가 하나 더 있습니다. 타입 표기를 쓰면 리터럴에서 빠뜨린 timeout?: number도 number | undefined로 읽히고, 읽는 쪽마다 undefined가 무슨 뜻인지 정해야 합니다. satisfies를 쓰면 그 속성은 추론된 타입에 아예 없어서 config.timeout은 TS2339, 존재하지 않는 속성 오류가 됩니다.

더 날카로운 답이고, 다른 답이기도 합니다. 나중에 리터럴에 timeout을 넣으면 거부되던 읽기 코드가 전부 컴파일되기 시작합니다. 호출하는 쪽이 값이 없는 경우를 처리해야 하는지, 아예 보지 말아야 하는지로 고르면 됩니다.

내보내는 객체라면 저는 반대로 가겠어요. satisfies 객체는 리터럴 타입까지 같이 내보내니까, config를 가져다 쓰는 모듈은 전부 그 안의 값에 기대게 돼요. 'dark'를 'light'로 바꾸면 세 파일 떨어진 곳의 비교가 컴파일되지 않아요. 그 코드는 타입이 아니라 값에 기대고 있었던 건데, 아무도 그렇게 하자고 정한 적이 없어요. 애플리케이션 설정이라면 저는 여전히 타입 표기가 나아요. Config는 코드가 기대도 되는 것만 말해요. 그뿐이에요.

루트에 쓴 리터럴 얘기는 실제보다 단순하게 들려요. satisfies가 쓴 리터럴을 전부 유지하는 건 아니에요.

type Config = { mode: 'light' | 'dark'; port: number };

const config = { mode: 'dark', port: 8080 } satisfies Config;

const m: 'dark' = config.mode;  // ok
const p: 8080 = config.port;    // error, port is number

port는 Config가 문맥 타입으로 number를 주기 때문에 number로 넓어져요. mode가 'dark'로 남는 건 Config가 그걸 문자열 리터럴 유니온으로 선언했기 때문일 뿐이에요. 그러니까 유지되는 건 더 구체적인 추론 타입이고, 얼마나 구체적인지는 Config에 달려 있어요. 가져다 쓰는 모듈이 값에 기대게 된다는 걱정도 mode에는 해당되고 port에는 대체로 해당되지 않아요.

그러니까 사용자가 설정 화면에서 다크 테마를 고르면, 그 선택이 JSON 파일에 써져요. 다음에 앱을 켜면 그 파일을 다시 읽는데, satisfies는 거기 근처에도 간 적이 없어요(소스에 있는 리터럴만 봤으니까요). 리터럴 config는 'dark'라고 하는데 저장된 파일에는 'Dark'가 있을 수도, 아무것도 없을 수도 있어요. 다들 satisfies 객체는 기본값으로 두고, 저장된 파일은 런타임 검사로 Config에 맞춰 파싱하나요? 아니면 둘이 어긋나지 않게 하는 방법이 따로 있는데 제가 모르는 건가요?

직접 해 보고 제 질문에 제가 답해요. satisfies 리터럴은 defaults가 됐고, 저장된 파일은 작은 parseSettings(raw: unknown): Partial<Config>를 거치고, 앱은 const config: Config = { ...defaults, ...saved }로 돌아가요. 합친 값에 타입 표기를 붙이니까 selim70님이 걱정한 부분도 해결돼요. 가져다 쓰는 모듈은 Config만 보거든요.

발목을 잡은 건 파서였어요. 처음 버전은 아는 키를 전부 복사하고, 값이 이상하면 undefined를 넣었어요. 그런데 명시적인 undefined를 스프레드하면 기본값이 지워지고, 타입은 아무 말도 안 했어요(그 프로젝트엔 exactOptionalPropertyTypes가 꺼져 있었거든요). 그래서 손으로 "Dark"라고 적은 사용자는 다크도 라이트도 아닌, 아무것도 선택 안 된 테마 선택 화면을 보게 됐어요. 지금은 파서가 잘못된 키를 아예 빼고, 설정 화면에 저장된 값 하나를 무시했다는 짧은 안내를 띄워요.