Implicitly has an any type w TypeScript

Jeśli dopiero zaczynasz pracę z TypeScriptem, prawdopodobnie szybko natknąłeś się na czerwone podkreślenie i komunikat zawierający frazę implicitly has an 'any' type. To jeden z najczęściej wyszukiwanych błędów TypeScriptu w ogóle — i mimo groźnie wyglądającej treści, jego naprawienie zajmuje zwykle dosłownie jedną linijkę kodu.

Co właściwie oznacza ten błąd?

TypeScript stara się sam odgadnąć (wywnioskować) typ każdej zmiennej, parametru i właściwości obiektu. Gdy nie ma wystarczających danych, żeby to zrobić, domyślnym wyjściem byłoby przypisanie typu any — czyli "wyłącz kontrolę typów dla tej wartości". Problem w tym, że any po cichu niweluje całą przewagę TypeScriptu nad JavaScriptem, więc kompilator w trybie strict zamiast zgadywać, zgłasza błąd i zmusza Cię do podjęcia decyzji.

Dlaczego TypeScript to zgłasza — noImplicitAny

Za tym zachowaniem stoi opcja noImplicitAny w tsconfig.json. Jest ona częścią flagi strict: true, która jest domyślnie włączona w szablonach TypeScript dla Vite, Next.jsa i create-react-app — czyli w praktyce w większości nowych projektów, które widzi dzisiejszy junior. Bez tej flagi powyższy kod skompilowałby się bez ostrzeżenia, a any wkradłoby się do projektu niezauważone.

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

Trzy najczęstsze warianty tego błędu

1. Parametr funkcji bez typu (TS7006)

// ❌ Parameter 'price' implicitly has an 'any' type
function addVAT(price) {
  return price * 1.23;
}

// ✅ jawna adnotacja typu
function addVAT(price: number): number {
  return price * 1.23;
}

2. Indeksowanie obiektu nieznanym kluczem

const prices = { bread: 4.5, milk: 3.2 };

// ❌ Element implicitly has an 'any' type...
function getPrice(product: string) {
  return prices[product];
}

// ✅ dodaj index signature albo typ Record
const prices: Record<string, number> = { bread: 4.5, milk: 3.2 };

3. Import nieotypowanej biblioteki JS

// ❌ Could not find a declaration file for module 'some-old-library'
import something from "some-old-library";

Najpierw sprawdź, czy istnieje pakiet z typami: npm install --save-dev @types/some-old-library. Jeśli nie istnieje, dodaj własną, minimalną deklarację w pliku *.d.ts:

// global.d.ts
declare module "some-old-library";

any czy unknown? Bezpieczniejsza alternatywa

Zanim sięgniesz po any jako "szybką łatkę", sprawdź unknown. Oba typy przyjmą dowolną wartość, ale unknown zmusza Cię do sprawdzenia typu przed użyciem — więc zachowujesz bezpieczeństwo, które jest całym sensem używania TypeScriptu.

function handleResponse(data: unknown) {
  // ❌ data.length — błąd kompilacji, data może być czymkolwiek
  if (typeof data === "string") {
    console.log(data.length); // ✅ TypeScript wie już, że to string
  }
}

Czy warto całkowicie zablokować any w projekcie?

Wiele zespołów idzie o krok dalej i włącza regułę @typescript-eslint/no-explicit-any, która zgłasza błąd lintera przy każdym jawnym użyciu any w kodzie — niezależnie od tego, czy TypeScript sam by się o to dopytał.

To jednak nie znaczy, że any jest zawsze błędem. W odcinku Czas na TypeScript naszego podcastu Michał Miszczyszyn tłumaczy Mateuszowi Bogolubowowi, kiedy świadome użycie any bywa rozsądnym kompromisem — np. przy szybkim prototypowaniu albo granicach systemu, których i tak nie kontrolujesz w 100%.

Różnica między "nie wiem, jaki to typ, więc wezmę any" (błąd, który naprawiasz) a "wiem, jaki to typ, i świadomie decyduję się na any" (decyzja, którą podejmujesz) jest tym, co TypeScript próbuje wymusić przez błąd implicitly has an 'any' type — i tym, czego warto się nauczyć najszybciej, przechodząc z JavaScriptu na TypeScript.