How to Fix “Type 'null' Is Not Assignable to Type” in TypeScript

TypeScript 7.0, released on July 8, 2026, moved the compiler to a new native implementation, but Microsoft says the port preserves the type-checking semantics developers already relied on. That matters here because the familiar Type 'null' is not assignable to type ... error is still fundamentally about your data model: a value may be null, while the destination type says it may not be.

In other words, there is no new TypeScript 7-specific trick to learn. The right fix is still to decide whether null is valid data, guard against it when it is not yet safe to use, or provide a deliberate fallback. The official TypeScript 7.0 announcement explains the compiler transition, while the current strictNullChecks documentation continues to define null and undefined as distinct types when strict null checking is enabled.

Why TypeScript says “Type 'null' is not assignable to type”

The error appears when an expression can evaluate to null but the receiving type excludes null. A minimal example is:

let name: string = null;

With strictNullChecks enabled, string means a real string value. It does not silently include null. The compiler therefore rejects the assignment instead of letting a possible missing value flow into code that assumes string methods are safe.

Turning off strictNullChecks can make the diagnostic disappear, but it also removes an important class of checks. TypeScript's own configuration reference warns that ignoring null and undefined can lead to unexpected runtime errors. For most maintained applications, fixing the model or the control flow is safer than disabling the check.

Choose the fix based on what null means in your program

Before changing syntax, decide what the missing value represents. The most maintainable solution depends on that answer.

Fix 1: Include null in the type when null is legitimate

If a variable genuinely has a “not available yet” or “no value” state, model that state explicitly:

let name: string | null = null;

name = "Avery";

Detta är inte en lösning. Det är ett korrekt kontrakt. En profils mellannamn, ett valfritt databasresultat eller ett valt objekt som börjar tomt kan rimligen vara nullvärde. När typen anger string | nullmåste nedströmskod bevisa att värdet är en sträng innan strängoperationer kan användas.

Använd den här metoden när anropare behöver skilja på "det finns inget värde" från ett verkligt värde. Lägg inte till | nullreflexmässigt bara för att tysta kompilatorn; det gör att hanteringskravet skjuts utåt.

Åtgärd 2: Begränsa värdet innan du använder det

Om ett nullvärde blir säkert efter en kontroll, låt TypeScripts kontrollflödesanalys begränsa typen. Den officiella handboken för inskränkning visar att kontroller som " value !== nullremove" nullfrån typen inuti den skyddade grenen.

function printLength(text: string | null) {
  if (text === null) {
    console.log("No text");
    return;
  }

  console.log(text.length);
}

Efter den tidiga återkomsten textär känt för att vara en string. Detta mönster skalar bra eftersom säkerhetskontrollen håller sig nära den punkt där antagandet blir sant.

Använd en exakt nullkontroll när falska värden är giltiga

Ett villkor som if (text)exkluderar även tomma strängar eftersom ""är falskt. Om en tom sträng är meningsfull, föredras text !== null. Om värdet kan vara antingen nulleller undefined, value != nullär en koncis JavaScript-kontroll som exkluderar båda; TypeScript förstår den förträngningen som dokumenteras i handboken.

Åtgärd 3: Ange en standardvärde med nullish-koalescingoperatorn

Om din affärslogik har en riktig reservfunktion, konvertera avsiktligt det nullvärde till ett icke-nullvärde:

const rawName: string | null = getDisplayName();
const displayName: string = rawName ?? "Guest";

Operatorn ??använder endast värdet till höger när vänster sida är nulleller undefined. Det gör den till ett bättre standardverktyg än ||när värden som "", 0eller falseär giltiga och bör bevaras.

Den här lösningen är idealisk för etiketter, konfigurationsstandardvärden och visningsvärden. Den är mindre lämplig när programmet måste veta om ett värde verkligen saknades, eftersom reservlösningen avsiktligt döljer den skillnaden.

Åtgärd 4: Använd endast den icke-null-baserade påståendeoperatorn när du redan har en garanti

Postfixet !anger att TypeScript ska behandla ett värde som icke-null och icke-odefinierat:

const element = document.getElementById("status");
element!.textContent = "Ready";

Detta kompilerar eftersom !tar bort den nullvärdesbara delen för typkontroll. Det lägger inte till någon runtime-kontroll. Om elementet inte finns kan koden fortfarande misslyckas när den försöker komma åt textContent.

Använd !endast när någon annan invariant verkligen garanterar att värdet existerar och kompilatorn inte kan uttrycka eller härleda den invarianten. För DOM-sökningar, begärandedata, cacheläsningar och användarinmatning är en riktig kontroll vanligtvis mer robust:

const element = document.getElementById("status");
if (element) {
  element.textContent = "Ready";
}

En bra fråga vid kodgranskning är: ”Vad framtvingar detta värde vid körning?” Om svaret bara är ”vi förväntar oss det” döljer påståendet förmodligen en bugg snarare än att åtgärda en.

Åtgärd 5: Korrigera funktionen eller objekttypen vid källan

Ibland är uppdragssidan oskyldig och det verkliga problemet är ett vilseledande kontrakt. Anta att en sökning returnerar nullnär ingen kund finns:

type Customer = { id: string; name: string };

function findCustomer(id: string): Customer | null {
  // Return a customer when found; otherwise return null.
  return null;
}

Om funktionen skrevs som endast returnerar Customer, skulle anropare få veta att fel är omöjligt trots att implementeringen säger något annat. Föredrar att fixa returtypen och tvinga anropare att hantera det saknade fallet.

Samma princip gäller för gränssnitt. Om ett API-fält explicit kan innehålla JSON null, modellera det som field: string | null. Om en egenskap kan saknas field?: stringrepresenterar en valfri egenskap, till exempel frånvaro genom undefined, inte explicit null. Om båda formerna förekommer kan modellen behöva field?: string | null.

Åtgärd 6: Använd NonNullable för återanvändbara typtransformationer

TypeScript inkluderar det globala NonNullable<Type>verktyget, som tar bort nulloch undefinedfrån en typ. Den officiella dokumentationen för verktygstyper listar det som en standardtyptransformation.

type MaybeName = string | null | undefined;
type Name = NonNullable<MaybeName>; // string

Detta är användbart när man härleder en typ för ett validerat lager, men det validerar inte värden i sig självt. Du behöver fortfarande ett runtime-kontrollflöde för att bevisa att det faktiska värdet inte är null innan du returnerar eller skickar det som den icke-nullvärdiga typen.

Vad sägs om "som en sträng"?

En typpåstående som value as stringkan undertrycka felet, men den har samma kärnbegränsning som !: den ändrar vad kompilatorn tror utan att kontrollera körtidsvärdet. Det är endast lämpligt när du har extern kunskap som TypeScript inte kan härleda. Det bör inte vara standardsvaret på nollställbara data.

const value: string | null = getValue();
const forced = value as string; // Compiles, but may still be null at runtime

Om du behöver bevisa att värdet är en sträng, föredra validering:

const value: string | null = getValue();
if (typeof value !== "string") {
  throw new Error("Expected a string");
}

const safeValue: string = value;

"Åtgärda" inte problemet genom att inaktivera strictNullChecks

Med strictNullCheckssatt till falseignorerar TypeScript till stor del nulloch undefinedi tilldelningsmöjligheter. Det kan göra äldre kod enklare att kompilera, men det tar också bort kompilatorns möjlighet att flagga många sökvägar för saknade värden före körning. Den nuvarande dokumentationen för typkompatibilitet , uppdaterad i september 2026, skiljer fortfarande på beteendet hos null-värden beroende på detta alternativ.

Om du migrerar ett stort äldre projekt kan det krävas en stegvis rensning för att aktivera strängare kontroller. Även då bör du betrakta inaktivering av nullkontroll som en migreringsbegränsning, inte som den föredragna lokala lösningen för ett enskilt fel.

En praktisk felsökningssekvens

1. Läs destinationstypen. Om det står string, User, eller någon annan konkret typ, fråga om det nullverkligen borde vara tillåtet där.
2. Spåra var null anges. Kontrollera funktionens returtyp, objektegenskap, sökresultat, databas-/API-modell, DOM-fråga eller initialtillstånd.
3. Välj den semantiska lösningen. Modellera null med en union, begränsa den, ge en reservfunktion eller korrigera källkontraktet.
4. Använd endast påståenden för reella invarianter. Ett icke-null-påstående eller typpåstående bör dokumentera kunskap du verkligen besitter, inte sudda ut osäkerhet.
5. Kör kompilatorn igen och testa null-sökvägen. En ren version visar att typrelationen är acceptabel; ett körtidstest visar att ditt beteende för saknade värden faktiskt matchar produktkravet.

Vanliga exempel och det bästa svaret

En sökning kan misslyckas

const user = users.find(u => u.id === id);

Array.prototype.findkan returnera undefined, så skydda resultatet eller ge en reservfunktion. Detta är samma resonemang som för ett nullvärde även om den saknade typen är undefinedsnarare än null.

Ett databas- eller API-fält returnerar explicit null

Behåll | nullgränstypen om det är vad det externa kontraktet faktiskt skickar. Konvertera eller validera sedan vid gränsen där din applikation kräver ett verkligt värde.

En variabel börjar tom men måste fyllas i senare

Använd en nullbar union under den fas där "not ready" är legitim, eller omstrukturera koden så att konstruktionen kräver värdet. Föredra den andra metoden när ett fullständigt initialiserat objekt aldrig ska existera i ett partiellt tillstånd.

Slutsats

Den säkraste lösningen för "Typen 'null' kan inte tilldelas till typ" är inte en enda operator. Det handlar om att välja en typ som återspeglar verkligheten och sedan få kontrollflödet att matcha den typen. Använd T | nullnär null är giltigt, explicit förträngning när värdet måste kontrolleras, ??när en verklig reservfunktion finns och !endast när en runtime-garanti finns utanför TypeScripts vy.

TypeScript 7.0 ändrar kompilatorarkitekturen, inte denna designprincip. Om din kod säger att ett värde inte kan vara null, gör det uttrycket sant vid körning såväl som i typsystemet.