TypeScript Types Deep Dive: Primitives, Literals, and Escape Hatches

In Part 2, we saw the TypeScript compiler strip type syntax at compile time — the : string, : User, the interface blocks, all gone. But what exactly are those types?

Before TypeScript can validate a single line of your code, it needs a type system to validate against.

This post covers that type system from the ground up: the 7 primitives TypeScript inherits from JavaScript, how type inference works, what literal types are, and the three special types that every TypeScript developer eventually has to understand — any, unknown, and never.

The 7 Primitive Types

TypeScript is built on JavaScript, so it starts with JavaScript’s 7 primitive value types. These are the atoms of the type system — every other type you’ll ever write is built from combinations of these.

Click through each type below to see what values it accepts, what the TypeScript compiler rejects, and what typeof returns for it at runtime:

let greeting: string = "Hello, World!";
let name = "Alice";           // inferred: string
let msg = `Hi ${name}!`;      // template literal: also string

// ❌ Error: Type 'number' is not assignable to type 'string'
greeting = 42;

let age: number = 30;
let price = 9.99;             // inferred: number

// NaN and Infinity are valid numbers in TypeScript
let ratio: number = NaN;
let limit: number = Infinity;

// ❌ Error: Type 'string' is not assignable to type 'number'
age = "thirty";

// ❌ Error: Type 'bigint' is not assignable to type 'number'
age = 30n;

let isLoggedIn: boolean = true;
let hasPermission = false;    // inferred: boolean

function toggle(flag: boolean): boolean {
  return !flag;
}

// ❌ These are NOT boolean in TypeScript:
// isLoggedIn = 0;     // Error: Type 'number' is not assignable
// isLoggedIn = null;  // Error: Type 'null' is not assignable

// With strict mode enabled (recommended):
let user: string | null = null;  // must be explicit
user = "Alice";                   // ✓ OK
user = null;                      // ✓ OK

// ❌ null not allowed without the | null union:
// let name: string = null;  // Error in strict mode

// Safe null check (TypeScript narrows here):
if (user !== null) {
  user.toUpperCase(); // TypeScript knows: user is string here
}

let count: number | undefined;
console.log(count);              // undefined (not yet set)

function greet(name?: string) {  // name: string | undefined
  if (name !== undefined) {
    return "Hello, " + name;     // TypeScript knows name is string
  }
  return "Hello, stranger!";
}

greet("Alice"); // "Hello, Alice"
greet();        // "Hello, stranger!" — name is undefined

const id1 = Symbol("id");
const id2 = Symbol("id");

id1 === id2; // false — always unique!

// Unique object keys that cannot accidentally collide:
const KEY = Symbol("myKey");
const obj = { [KEY]: "hidden value" };

// Well-known built-in symbol:
class NumberRange {
  constructor(public start: number, public end: number) {}
  [Symbol.iterator]() {
    let n = this.start;
    const end = this.end;
    return { next: () => n <= end
      ? { value: n++, done: false }
      : { value: undefined, done: true as const }
    };
  }
}

for (const n of new NumberRange(1, 3)) {
  console.log(n); // 1, 2, 3
}

const big: bigint = 9007199254740991n; // n suffix required
const larger = big + 1n;               // inferred: bigint

// ❌ Cannot mix bigint and number:
// big + 1   // Error: Cannot mix BigInt and other types

// ✅ Always use n suffix in bigint arithmetic:
big + 1n; // OK

// Convert from number:
const fromNum = BigInt(42);   // 42n

// Large IDs stay precise (regular number would lose precision):
const tweetId: bigint = 1234567890123456789n;

A few things worth noting across all 7:

typeof isn’t always what you expect. The runtime typeof for null is "object" — a famous JavaScript bug from 1995 that TypeScript inherits. Never use typeof x === "object" to check for null; always use x === null directly.

TypeScript maps types to runtime values. When you write : string, TypeScript knows the value will be a JavaScript string at runtime. The type system mirrors JavaScript’s underlying value model — it doesn’t invent new runtime behaviors.

Strict mode matters for null and undefined. With strictNullChecks: true (enabled by the strict flag in tsconfig.json), null and undefined are not assignable to other types unless you explicitly include them in a union. This catches a huge class of runtime bugs. Always use strict mode.

Type Inference: TypeScript Reads Your Mind

You don’t need to write types everywhere. TypeScript watches what values you assign to variables and infers the type automatically.

Here’s the same add function in JavaScript versus TypeScript — see how TypeScript catches the mistake that JavaScript silently accepts:

// JavaScript — types are unknown until runtime
function add(a, b) {
return a + b;
}

add(1, 2);     // 3
add(1, "2");   // "12" — silent string concatenation!
add([], {});   // "[object Object]" — no error, wrong result

// TypeScript — types known while you type
function add(a: number, b: number): number {
return a + b;
}

add(1, 2);     // 3 ✓
add(1, "2");   // ❌ Argument of type 'string' is not assignable to type 'number'
add([], {});   // ❌ Argument of type 'never[]' is not assignable to type 'number'

Notice that we didn’t annotate the return type on the TypeScript version in that example — TypeScript infers number because it sees two number parameters being added. Inference is working behind the scenes.

When to annotate, when to let TypeScript infer

A practical rule that experienced TypeScript developers use:

The goal is to write fewer type annotations, not more. Let TypeScript do the work wherever it can.

Literal Types: Narrow is More Precise

Here’s something that surprises most developers learning TypeScript: a type can be a specific value, not just a category of values.

string means “any string.” But "Alice" (with quotes) means “only the string Alice, nothing else.” These are called literal types.

Literal types exist for all three of the primary primitives:

type Direction = "north" | "south" | "east" | "west"; // string literals
type DiceRoll = 1 | 2 | 3 | 4 | 5 | 6;               // number literals
type Answer = true | false;                             // boolean literals (same as boolean)

The Direction type above only accepts exactly those four string values. Pass "northwest" and TypeScript rejects it immediately.

const vs let: the inference difference

This is where literal types get genuinely surprising. TypeScript infers different types for const and let even when they start with the same value:

let status = "active";   // inferred: string  (wide — can be reassigned)
const mode = "active";   // inferred: "active" (narrow — can never change)

With let, TypeScript widens the type to string because the variable could be reassigned to any string later. With const, it knows the value is fixed — so it infers the most precise type possible, the literal "active".

This matters in practice. If you write a function that expects "active" | "inactive" and you try to pass a let variable, TypeScript might reject it even though the value happens to be correct:

type Status = "active" | "inactive";

function setStatus(s: Status) { /* ... */ }

let s = "active";    // TypeScript infers: string (too wide!)
setStatus(s);        // ❌ Error: Argument of type 'string' is not assignable to type 'Status'

const s2 = "active"; // TypeScript infers: "active" (exactly right)
setStatus(s2);        // ✓ OK

Fix: use const, add an explicit type annotation (let s: Status = "active"), or use as const — which we’ll cover in Part 9.

The Special Three: any, unknown, and never

Beyond the 7 primitives, TypeScript has three special types that represent categories of values rather than specific JavaScript value kinds. These are the types you reach for when the primitive types aren’t enough — or when you need to handle values that TypeScript itself uses internally.

let x: any = "hello";
x = 42;           // ✓ OK — any accepts anything
x = { a: 1 };    // ✓ OK

// TypeScript won't stop you — these silently crash at runtime:
x.toUpperCase();  // TS: OK  |  Runtime: crashes if x is a number
x();              // TS: OK  |  Runtime: crashes if x is not a function

// Spreads unsafety to other variables:
const n: number = x; // TS: OK  |  Runtime: x could be anything

// Rule of thumb: avoid any. Use unknown instead.

function process(value: unknown) {
  // ❌ Cannot use directly:
  // value.toUpperCase(); // Error: Object is of type 'unknown'
  // value();             // Error: Cannot invoke an object of type 'unknown'

  // ✅ Narrow the type first, then use it:
  if (typeof value === "string") {
    value.toUpperCase(); // TypeScript knows: value is string here
  }
  if (typeof value === "number") {
    value.toFixed(2);    // TypeScript knows: value is number here
  }
}

// Perfect for API responses and catch blocks:
try {
  const res = await fetch("/api/user");
  const data: unknown = await res.json(); // unknown until validated
} catch (err: unknown) {
  if (err instanceof Error) {
    console.error(err.message); // safe: err is Error here
  }
}

// Functions that never return:
function fail(msg: string): never {
  throw new Error(msg); // never completes normally
}

function forever(): never {
  while (true) {} // never terminates
}

// Exhaustiveness check — catches missing cases at compile time:
type Shape = "circle" | "square" | "triangle";

function area(s: Shape): number {
  if (s === "circle")   return Math.PI;
  if (s === "square")   return 1;
  if (s === "triangle") return 0.5;

  // All cases handled — TypeScript infers s as never here.
  // Add "pentagon" to Shape without a case → Error on this line:
  const _exhaustive: never = s;
  return _exhaustive; // unreachable, but TypeScript is happy
}

The practical guide: which one to use

Reach for unknown instead of any whenever you genuinely don’t know the type yet. Both accept all values, but unknown forces you to check before using — which means bugs get caught at compile time instead of production.

// ❌ any — compiles, crashes silently at runtime:
function processAny(data: any) {
  data.name.toUpperCase(); // TypeScript: OK. Runtime: possible crash.
}

// ✅ unknown — TypeScript catches the bug:
function processUnknown(data: unknown) {
  if (typeof data === "object" && data !== null && "name" in data) {
    const name = (data as { name: unknown }).name;
    if (typeof name === "string") {
      name.toUpperCase(); // TypeScript: OK. Runtime: safe.
    }
  }
}

never shows up in three places:

1. Functions that always throw or loop forever — their return type is never because they never produce a value
2. Exhaustiveness checks — when you’ve narrowed all possibilities away, TypeScript infers never, which lets you build compile-time checks that catch missing union cases
3. Impossible intersections — string & number is never because no value can be both

You almost never write never directly. TypeScript infers it. But recognizing it when you see it is important — never on a variable usually means “you’ve already handled all the possible cases.”

What You’ve Learned

You now have a complete picture of TypeScript’s foundational type system:

1. 7 primitive types — string, number, boolean, null, undefined, symbol, bigint. TypeScript maps directly to JavaScript’s runtime value types.
2. Type inference — TypeScript reads initializer values and infers types automatically. Annotate function parameters; let inference handle the rest.
3. Literal types — A type can be a specific value ("active", 42, true). const infers literal types; let widens to the primitive.
4. any — disables all checking. Use only during JS → TS migration.
5. unknown — accepts all values, but forces narrowing before use. Always prefer over any.
6. never — represents impossibility. Appears in unreachable code paths and exhaustiveness checks.

Next up in this series: Objects, Arrays, and Tuples — how to describe the shape of structured data in TypeScript.