`noImplicitAny`

"Compiler 가 뭐가 어떤 타입인지 못 알면, default 가 '뭐든 OK' 면 안 됨."

뭐 잡아

noImplicitAny 없으면 compiler 가 annotation 없고 추론 불가능한 값을 조용히 any 로 타입. Annotation 없고 callsite 추론 못 하는 함수 parameter? any. 초기화 또는 annotation 없이 선언된 변수? any. '나 체크하지 마' 타입이 경고 없이 codebase 통해 퍼짐.

Flag 켜지면 그런 모든 case 가 compile 에러. Annotate 하거나 inference 성공 가능하게 코드 다시 써야. 명시 any (: any) 는 여전히 허용 — flag 는 암묵 case 만 잡음.

왜 가장 중요한 strict flag

7 strict-family flag 중 noImplicitAny 가 가장 넓은 카테고리의 latent 안전 부족 잡음. 기초; 다른 거 위에 빌드. Strict 아닌 codebase 를 strict 로 migration 할 때 이거 먼저 켜.

Migration playbook

Legacy codebase 에 noImplicitAny 켜면 보통 수백 에러. Migration 경로:

먼저 hot-path public API annotate.
Leaf 부터 안쪽으로 파일별로 sweep.
진짜 타입 없는 case 엔 IDE 의 quick-fix 써서 any 명시 삽입. 이게 암묵 any 들을 아무것도 깨지 않고 visible 하게.
시간이 지나며 각 명시 any 를 진짜 타입으로 대체.

noImplicitAny 가 'type system 이 내 버그 잡음' 과 'type system 이 어깨 으쓱하고 통과시킴' 사이의 선. 항상 켜놔.

Code

암묵 vs 명시 any·typescript

// noImplicitAny 없이 — 조용히 `any` 타입.
function loose(x) {
  return x.toUpperCase();    // ✅ 컴파일 — x 가 암묵 any
}
loose(42);                    // runtime 에 크래시

// noImplicitAny 와 함께:
function strict(x) {          // ❌ Parameter 'x' implicitly has 'any' type
  return x.toUpperCase();
}

// Fix 1: annotate.
function strictFix(x: string): string {
  return x.toUpperCase();
}

// Fix 2: 명시 any (아직 진짜 모를 때).
function quickFix(x: any) {
  // any 명시 사용 — 최소한 reader 가 봄
  return x.toUpperCase();
}

Exercise

Annotate 안 하고 parameter 받는 함수 써. noImplicitAny 끄고, 그다음 켜. Flag 켜진 상태에만 compile 에러 나타나는 거 적어. 이제 parameter annotate — 에러 사라짐. 이제 잘못된 타입 전달하는 callsite 써 — type system 이 잡음.

Hint

Flag 가 binary. 끄면 optional 타입 있는 JavaScript. 켜면 TypeScript. 대부분 프로젝트가 flag 없는 codebase 시도하기 전까진 flag 가 얼마나 많이 일하는지 잊음.

뭐 잡아

왜 가장 중요한 strict flag

Migration playbook

Code

External links

Exercise

Progress

댓글 0