답변.

질문의 배경

TypeScript는 JavaScript에서 최대한 부드럽게 전환할 수 있도록 처음 설계되었습니다. 따라서 기본적으로 명시적인 유형이 없는 변수나 매개변수는 any 유형을 가집니다. 이는 이전 작업을 용이하게 했지만 정적 유형의 장점을 감소시킵니다. 코드의 신뢰성과 예측 가능성을 높이기 위해 TypeScript 팀은 noImplicitAny 컴파일러 플래그를 도입하여 명시적으로 타입을 지정하거나 TypeScript가 올바르게 유형을 추론할 수 있게 요구합니다.

문제

noImplicitAny가 비활성화되어 있으면 개발자는 변수, 매개변수 또는 함수 반환 값의 유형을 명시적으로 지정하는 것을 실수로 놓칠 수 있습니다. 이는 코드를 덜 안전하게 만들어 리팩토링을 어렵게 하며, 타입과 관련된 모든 오류가 컴파일 시 발견되지 않고 런타임에서만 나타납니다.

해결책

tsconfig.json 파일에서 noImplicitAny를 활성화하면 TypeScript 컴파일러는 암 implicit하게 any 유형을 사용할 때마다 오류를 발생시킵니다. 이는 개발자에게 유형에 대한 주의 깊은 접근을 요구하고 리팩토링 프로세스를 덜 위험하게 만들며, 코드 자체를 더 신뢰할 수 있게 만듭니다.

코드 예시:

// tsconfig.json
{
  "compilerOptions": {
    "noImplicitAny": true
  }
}

// 매개변수 유형이 지정되지 않은 함수 예시
function printUser(user) {
  console.log(user.name); // 타입이 지정되지 않으면 컴파일 오류
}

// 올바르게:
function printUser(user: { name: string }) {
  console.log(user.name);
}

주요 특징:

애매한 모든 장소에서 명시적으로 유형을 지정해야 합니다.
컴파일 단계에서 대부분의 타입 오류를 발견할 수 있습니다.
대규모 프로젝트에서 코드의 높은 예측 가능성과 안전성을 보장합니다.

트릭 질문들.

noImplicitAny를 활성화하면 프로젝트 내의 모든 잠재적 타입 오류를 방지할 수 있나요?

아니요, 이 플래그는 암시적 any만 제거합니다. 명시적 사용은 여전히 허용됩니다. 완전한 보호를 위해서는 linting과 리뷰를 통해 명시적인 any를 제한해야 합니다.

자동으로 타입이 추론되는 경우, noImplicitAny가 여전히 경고하나요?

아니요, TypeScript가 타입을 올바르게 추론할 수 있으면(예: 초기화에 의해) 오류는 발생하지 않습니다. 예를 들면:

let n = 123; // 타입은 number, not any

strict를 활성화하면 자동으로 noImplicitAny가 활성화되나요?

네, strict 플래그는 많은 엄격 검사를 활성화하며 그 중에 noImplicitAny도 포함됩니다. 그러나 필요에 따라 수동으로 비활성화할 수 있습니다.

일반 오류와 안티 패턴

여러 곳에서 명시적 any를 남겨두면 엄격한 유형 지정의 의미가 사라집니다.
큰 코드베이스에서 noImplicitAny 없이 프로젝트를 실행하고 "어쩌면 될 것"이라고 믿는 것은 많은 숨겨진 오류를 유발합니다.
"어느 정도, 컴파일되기만 하면"이라는 식으로 타입을 추가하고 올바른지에 대한 고려 없이 코드를 작성하지 마세요.

실제 사례

부정적 케이스

프로젝트에서 noImplicitAny가 비활성화되어 있으며, 대부분의 API 핸들러가 명시적인 유형 없이 매개변수를 받습니다. 새로운 비즈니스 로직을 도입할 때 개발자가 속성 이름에서 실수하지만 오류는 프로덕션에서만 나타납니다.

장점:

코드가 간단하고 빠르게 시작할 수 있습니다.
JS에서 마이그레이션이 더 쉬워집니다.

단점:

프로덕션에서 발견된 오류는 정적으로 발견될 수 있는 오류입니다.
리팩토링 및 확장이 복잡해집니다.

긍정적 케이스

noImplicitAny를 활성화한 후 모든 코드를 점진적으로 리팩토링하고 암시적 any를 제거했습니다. 유형 강조 및 자동 완성 기능이 있는 편집기를 사용하기 시작했습니다. 새로운 오류가 발생하면 즉시 빌드 단계에서 수정됩니다.