Primitive Types, Inference and Type Annotations

Every value in a TypeScript program has a type, and the most fundamental of these are the primitives — the irreducible building blocks like `string`, `number`, and `boolean` from which every richer structure is composed. Getting primitives right matters because almost every bug in a typed program traces back to a value being treated as the wrong kind of thing, and primitives are where those distinctions begin. Equally important is understanding two complementary ways the compiler learns a value's type: inference, where it deduces the type from how you initialise a value, and annotation, where you state the type explicitly. Without a firm grasp of both, developers either annotate everything and produce noisy, brittle code, or annotate nothing and lose the precision that makes typing worthwhile. Knowing when each applies is the difference between code that reads cleanly and stays correct and code that fights you at every turn.

Analogy🏏Cricket

🏏 Think of it like cricket: Picture how a scoreboard operator constructs every display string from fixed components in a strict format — a batter's line is always built as `${name} ${runs} (${balls})`, never improvised. The format is a template with slots, and only values that fit each slot are allowed. Just as the scoreboard builds each line by filling a fixed template with the right pieces, a template literal type builds a string type by filling a pattern with other types. Just as a stray entry that does not match the format — text where runs should go — is rejected by the operator, a string that does not match the template literal type is rejected by the compiler. Just as the format guarantees every line is readable and consistent, the template type guarantees every string matches the intended shape. This reveals why template literal types matter: strings in software follow patterns just like scoreboard lines, and encoding the pattern into the type makes every malformed string an immediate error.