Primitives

Alright, let’s talk about any’s smarter, more responsible cousin: unknown. If any is the developer who hacks everything together with duct tape and a prayer, unknown is the one who actually reads the instruction manual first. It’s a core tool for writing type-safe code, especially when you’re dealing with data from the outside world, like API responses, user input, or file contents—places where the type isn’t guaranteed. Here’s the fundamental truth about unknown: you can assign anything to a variable of type unknown. A string, a number, a complex object, a Promise of a bag of chips—whatever. It’s the “top type” in the type system, meaning every other type can be assigned to it. This is its superpower and its initial frustration.

Right, let’s talk about any. It’s the type system’s emergency exit hatch, its get-out-of-jail-free card, and frankly, its original sin. You use it when you want to tell TypeScript, “Back off, I know what I’m doing.” Spoiler alert: you often don’t. Think of TypeScript’s type system as a brilliant but overzealous personal assistant. It constantly checks your work, points out potential mistakes, and ensures everything you do is correct and consistent. The any type is you snapping, “I GOT THIS, JUST LET ME TYPE!” and shoving them out of the room. Suddenly, the red squiggles are gone. You have peace. You can assign a number to a string, call a function that doesn’t exist, and generally run amok. It feels like freedom. It’s not freedom; it’s anarchy, and it will eventually burn your house down.

Now, let’s talk about a feature that exists almost entirely to save your sanity and the sanity of the poor soul who has to read your code six months from now (which is probably you, hungover on a Sunday). I’m talking about labeled tuple elements. You’ve already met the basic tuple: a fixed-length array with a known type for each position. [string, number] means index 0 is a string, index 1 is a number. Simple, right? But also… profoundly dumb. What does const coordinates = [10, 20]; mean? Is that [x, y]? [latitude, longitude]? [price, quantity]? You and I might guess from context, but the TypeScript compiler has no idea. It just sees a string and a number. This is where labels come in. They add a layer of readability on top of the existing type structure without changing the underlying JavaScript behavior one bit.

Right, so you’ve got the basics of tuples down. You know they’re those wonderfully strict, fixed-length arrays that TypeScript uses to keep you honest. But what about when you need a little flexibility within that rigidity? That’s where optional and rest elements come in, and they’re the reason tuples stop being just “arrays with a known length” and start becoming genuinely powerful tools for modeling your data. Think of it like this: a regular tuple is a meticulously packed suitcase for a specific trip – exactly two pairs of shoes, three shirts, one suit. An optional element is like leaving a little extra space for that souvenir you might buy. A rest element is like strapping an extra, smaller bag to the outside for all the other little junk that accumulates. Both are ways to bend the rules without completely breaking them.

Alright, let’s talk about tuples. You’ve met arrays, which are great for lists of things where everything is the same type. But what about when you need a fixed-length, ordered structure where each position has a specific and potentially different type? Enter the tuple. Think of it as a formally defined couple or trio. It’s not “a list of stuff,” it’s “exactly two things: a string and a number, in that order.” This is incredibly useful for things like representing coordinates ([number, number]), key-value pairs ([string, any]), or returning multiple values from a function without the ceremony of creating a new object or class.

Right, let’s talk about arrays. You’ve got a bunch of things—numbers, strings, whatever—and you want to keep them in a nice, orderly line. TypeScript, being the helpful but occasionally pedantic friend that it is, demands to know what kind of things you’re putting in that line. This is where array types come in, and you’ve got two syntaxes to choose from. They do the same thing. Mostly. We’ll get to that.

Look, I get it. You’re busy. Writing : number after every variable feels like filling out tax forms in triplicate. The good news is, TypeScript’s type inference is shockingly good. It’s the language’s way of saying, “I see what you’re doing, I got this.” You can often just shut up and let it do its job. The Beautiful Simplicity of Initialization This is the most common and most reliable scenario. When you declare a variable and immediately assign a value to it, TypeScript locks in the type of that value as the variable’s type. It’s a one-and-done deal.

Alright, let’s get down to brass tacks. You’re writing JavaScript, but you want to do it properly. You’re tired of undefined is not a function and you’ve decided to enlist TypeScript’s help. Good choice. The first and most fundamental step is telling TypeScript what kind of stuff you’re putting in your variables. This isn’t bureaucracy; it’s a force field against your own future, dumb mistakes. We start with the primitives: the basic building blocks of data. You already know these from JavaScript, but now we’re going to be explicit about them.