Traps and escape hatches

At a busy railway station, the booking counter has a long queue. Now imagine a pass that lets you walk past the queue and straight onto the platform. Very handy. You save an hour.

But the pass only skips the counter. On the train, the ticket checker still walks down the aisle. If your ticket is wrong, you find out there, with everyone watching, and not at the counter where it was cheap to fix.

TypeScript has passes like this. They are called escape hatches: ways to tell the checker "let me through, I know what I'm doing". There are a handful: any, as, !, and a few comments. Each one switches off a check, for one value or one line.

They are not evil. Real projects need them, now and then. Without them, some honest code could not be written at all. The trouble is that each pass skips only the checker. It never makes the code correct. When the pass is wrong, the crash comes at runtime, which is exactly where TypeScript was supposed to keep you safe.

This lesson shows each pass, what it skips, when it is fair, and the ticket checker waiting after it. It also covers two traps that are not passes at all: enums, and the types object and {}.

Remember: an escape hatch skips the checker, not the crash. Use one only when you can say why it is safe.

In JavaScript, there is no counter at all. Everything gets the pass. Here is a function that shouts a word.

function shout(text) {  return text.toUpperCase();}console.log(shout("chai"));console.log(shout(42));

CHAI
TypeError: text.toUpperCase is not a function

The second call passes a number. Nothing at the counter. The crash is on the train.

The same thing happens with data. We read some JSON and use it as a user, but the data has no age.

const data = JSON.parse('{"name": "Asha"}');const user = data;console.log(user.name);console.log(user.age.toFixed(0));

Asha
TypeError: Cannot read properties of undefined (reading 'toFixed')

Remember: JavaScript is one big pass. TypeScript's job is to bring the counter back, and the escape hatches are how you put the pass back, one place at a time.

Pass 1: any. The widest pass. A value of type any can be used as anything: you can call it, read from it, pass it anywhere. Here is the shout function with the label any.

function shout(text: any): string {  return text.toUpperCase();}console.log(shout("chai"));console.log(shout(42));

CHAI

It compiles with no complaint, and the second call crashes, as in JavaScript. Nothing was checked. Now compare with the honest label.

function shout(text) {  return text.toUpperCase();}console.log(shout("chai"));console.log(shout(42));

function shout(text: string): string {  return text.toUpperCase();}console.log(shout("chai"));console.log(shout(42));

With text: string, the call with 42 is refused at the counter. any is also contagious: a value that touches an any often becomes any itself, so one pass can quietly spread across a file. Prefer unknown, from lesson 9, which makes you check first.

Pass 2: as. A type assertion (a cast) tells the checker "treat this value as this type". It changes nothing at runtime. It only changes what the checker believes.

type User = { name: string; age: number };const data: unknown = JSON.parse('{"name": "Asha"}');const user = data as User;console.log(user.name);console.log(user.age.toFixed(0));

Asha

The checker believes data is a User, so user.age.toFixed(0) compiles. At runtime there is no age, and the crash comes. This is lesson 9 again: as is the label on the parcel, not the check at the door.

But the checker still looks at casts in one case. It refuses when the two types have nothing in common.

const price = "12" as number;

The message even tells you the way around: go through unknown first. That is the double cast.

Pass 3: the double cast, as unknown as T. This is the forged pass. It works on anything, and the checker believes it.

// as unknown as is a forged pass: it compiles, and the value is still text.const price = "12" as unknown as number;console.log(typeof price);

string

The variable is typed as a number, and holds text. If you ever write this, add a comment saying why. In most code it is a sign that the types need fixing.

Pass 4: the bang, !. From lesson 6: the non-null assertion says "this is not null or undefined".

const names = ["Asha", "Ravi"];const found = names.find((name) => name === "Meena")!;console.log(found.toUpperCase());

find found no Meena, so found is undefined, and the call crashes. The ! only hid the warning. It's fair when the line above proves the value is there, and unfair when it is a hope.

Remember: any switches the checker off, as overrules it, ! silences it, and a double cast forges a pass. None of them checks the data.

Some escape hatches are not really escapes. They tell the checker more, not less.

as const. It says "treat this literal as exactly what it says, and don't change it". The exact words stay exact (lesson 5), and the properties become readonly.

const order = { kind: "chai", sugar: 2 } as const;// order.kind is the exact word "chai", and sugar can no longer be changed.console.log(order.kind);

chai

satisfies. This checks a value against a type, without changing the value's own type. You get the check of a label and the exact keys of the value.

type Prices = Record<string, number>;const prices = { chai: 10, coffee: 20 } satisfies Prices;// Checked against Prices, and still remembers exactly which keys exist.console.log(prices.chai.toFixed(0));

10

If you had written const prices: Prices = ..., TypeScript would only remember "a record of any text key", and prices.lassi would pass as a number. With satisfies, a missing key is an error.

type Prices = Record<string, number>;const prices = { chai: 10, coffee: 20 } satisfies Prices;console.log(prices.chai);console.log(prices.lassi);

A cast to a DOM element. The web page is outside TypeScript's sight, so it can't know that the element with id quantity is an input box. Here an as is fair, because you really do know your own HTML.

const box = document.getElementById("quantity") as HTMLInputElement;console.log(box.value);

Even so, the honest version checks first, with instanceof HTMLInputElement.

Here is a rule of thumb for deciding.

Remember: passes that tell the checker more, like as const and satisfies, are safe. Passes that tell it to look away, like any and !, need a reason.

Enums. An enum is a built-in way to name a set of related values. Many tutorials and other languages use them.

enum Drink {  Chai,  Coffee,  Lassi,}function priceOf(drink: Drink): number {  switch (drink) {    case Drink.Chai:      return 10;    case Drink.Coffee:      return 20;    case Drink.Lassi:      return 30;  }}console.log(priceOf(Drink.Coffee));

20

A union of exact words does the same job, with less baggage.

type Drink = "chai" | "coffee" | "lassi";const prices: Record<Drink, number> = {  chai: 10,  coffee: 20,  lassi: 30,};function priceOf(drink: Drink): number {  return prices[drink];}console.log(priceOf("coffee"));

20

This guide prefers the union, for these reasons.

• An enum is real code. Types vanish at runtime, but an enum doesn't. It becomes an object in your JavaScript. This is what the first line of that enum turns into.

var Drink;(function (Drink) {  Drink[Drink["Chai"] = 0] = "Chai";  Drink[Drink["Coffee"] = 1] = "Coffee";  Drink[Drink["Lassi"] = 2] = "Lassi";})(Drink || (Drink = {}));

• Node can't strip it. Lesson 1 showed Node running .ts files by erasing the types. That only works when removing the types leaves valid JavaScript, and an enum leaves nothing to remove, so Node refuses it. A union is only a type, so it strips cleanly.
• A numeric enum is too trusting. Any number is accepted where the enum is wanted.

enum Drink {  Chai,  Coffee,}function order(drink: Drink): Drink {  return drink;}// Any number at all is accepted where a numeric enum is wanted.const typed: number = 7;console.log(order(typed));

7

There is no drink number 7. The checker allows it anyway.

• A union reads as what it is. In the editor, "chai" is what you see, and what you type. With a numeric enum, you see 0.

Enums aren't banned. Existing code has them, and that's fine. For new code, a union is the simpler default.

object and {}. These look like "any object", and they are not.

const anything: {} = 42;const alsoAnything: {} = "chai";const onlyObjects: object = { kind: "chai" };

The type {} means "any value that is not null or undefined". A number and a piece of text both fit, which is rarely what you meant. The lowercase object means "something that isn't a basic value".

const anything: {} = 42;const onlyObjects: object = 42;

If you want "an object with keys I don't know yet", the clearest type is Record<string, unknown>.

function countKeys(value: Record<string, unknown>): number {  return Object.keys(value).length;}console.log(countKeys({ name: "Asha", age: 21 }));

2

A last short list of what to avoid. Capital-letter types like Object, String and Function (use object, string and a real function type). A @ts-ignore where @ts-expect-error would do (lesson 10). A // @ts-nocheck at the top of a file you mean to fix. And any cast whose reason you can't say out loud.

Remember: prefer a union of words to an enum, object to {}, and Record<string, unknown> for a bag of keys.

Each problem starts with JavaScript that has the loose version of something. Make it honest.

function lengthOf(value) {  return value.length;}console.log(lengthOf("chai")); // 4console.log(lengthOf([1, 2, 3])); // 3// lengthOf(42) gives undefined, and lengthOf(null) crashes

function lengthOf(value: unknown): number {  if (typeof value === "string" || Array.isArray(value)) {    return value.length;  }  return 0;}lengthOf("chai"); // 4lengthOf([1, 2, 3]); // 3lengthOf(42); // 0

const Size = { Small: "small", Large: "large" };function sizePrice(size) {  if (size === Size.Small) {    return 10;  }  return 20;}console.log(sizePrice("large")); // 20console.log(sizePrice("huge")); // 20, anything that is not small is priced as large

type Size = "small" | "large";const sizePrices: Record<Size, number> = {  small: 10,  large: 20,};function sizePrice(size: Size): number {  return sizePrices[size];}sizePrice("large"); // 20

const menuPrices = {  chai: 10,  coffee: 20,};console.log(menuPrices.chai); // 10console.log(menuPrices.lassi); // undefined, and nothing warned us

type Menu = Record<string, number>;const menuPrices = {  chai: 10,  coffee: 20,} satisfies Menu;menuPrices.chai; // 10

Expect "when would you use any?" as a test of judgment. The best answers are calm and specific.

• "What is the difference between any and unknown?" any turns checking off. unknown requires a check before use. Prefer unknown.
• "What does as do at runtime?" Nothing. It exists only for the checker, and it is erased like every type.
• "When is as acceptable?" When you know something the checker can't, such as a DOM element's type, and you can say why. Not as a replacement for checking outside data.
• "What does ! do?" The non-null assertion. It tells the checker a value isn't null or undefined, without checking.
• "What is satisfies?" An operator that checks a value against a type without changing the value's own type.
• "What is as const?" It makes a literal exactly what it says, with exact words and readonly properties.
• "Enums or union types?" Unions, for new code: they are only types, they don't need extra JavaScript, and Node can strip them. Enums are fine in existing code.
• "What is the difference between object and {}?" object is any non-primitive. {} is any value except null and undefined, including numbers and text.
• "@ts-ignore or @ts-expect-error?" @ts-expect-error, because it complains when the error is gone.
• Say it simply. "Escape hatches skip the checker, not the crash, so I use one only when I can say why it is safe" is a good answer.

Made by VeraStack Labs