Global Scope

The `Prettify` helper is a utility type that takes an object type and makes the hover overlay more readable.

```ts
type Prettify<T> = {
  [K in keyof T]: T[K];
} & {};
```

It's known by various names - `Id`, `Compute`, `Unwrap` - but each uses this same implementation.

It's also not globally available in TypeScript - you'll need to define it yourself using the code above.

## Example

Let's imagine that you've got a type with multiple intersections:

```typescript
type Intersected = {
  a: string;
} & {
  b: number;
} & {
  c: boolean;
};
```

If you hover over `Intersected`, you'll see the following:

```typescript
/**
 * { a: string; } & { b: number; } & { c: boolean; }
 */
```

This is a little ugly. But we can wrap it in `Prettify` to make it more readable:

```typescript
type Intersected = Prettify<
  {
    a: string;
  } & {
    b: number;
  } & {
    c: boolean;
  }
>;

/**
 * {
 *   a: string;
 *   b: number;
 *   c: boolean;
 * }
 */
```

Much better. This also works on more complex computations, as the [Remix team discovered](https://twitter.com/pcattori/status/1660648097985224705).

## Why This Works

It's not clear why using a mapped type and intersecting it with `{}` actually works. It's a quirk of the TypeScript compiler.

Oddly, intersecting it with `unknown` also works:

```typescript
type Prettify<T> = {
  [K in keyof T]: T[K];
} & unknown;
```

Does this make it likely to break in the future? No - TypeScript has tests to ensure that this code won't break, so you can consider `Prettify` safe to use.


The `Prettify` Helper

> Option 'module' must be set to 'NodeNext' when option 'moduleResolution' is set to 'NodeNext'

This error, new to TypeScript 5.2, might be happening for a few reasons. Let's break down all the reasons why it might be happening and how to fix it.

## I'm Transpiling With `tsc`

In this section, I'm going to assume that you're using `tsc` to transpile your code. I.e., you've set `noEmit` to `false`, and you're running `tsc` to produce JavaScript files. If you're not, you can skip to the next section.

### Problem 1: Your `module` Config is Outdated

Choosing `moduleResolution`: `NodeNext` indicates that the code you're writing is targeting Node. Your `module` might be set to `commonjs`.

#### Why doesn't `commonjs` work?

The reason `commonjs` no longer works is that TypeScript files can be written with `.mts` file extensions. This allows you to write some files which are ES Modules, and some which are CommonJS. Using `commonjs` with `.mts` file extensions mangles the output.

### Solution 1

Since TypeScript 5.2, any code written _for Node_ must use `module: "NodeNext"`.

Set `module` and `moduleResolution` to `NodeNext` in your `tsconfig.json`:

```json
{
  "compilerOptions": {
    "module": "NodeNext",
    "moduleResolution": "NodeNext"
  }
}
```

#### What about `Node16`?

`Node16` is also a valid option for `module` and `moduleResolution`:

```json
{
  "compilerOptions": {
    "module": "Node16",
    "moduleResolution": "Node16"
  }
}
```

Currently, this is equivalent to if both were set to `NodeNext`. However, using `NodeNext` is safer because it's future-proof - the module resolution algorithm might change in the future, and `NodeNext` will always use the latest version.

### Problem 2: `module` is Set to `ESNext`

All LTS Node versions now support ES Modules. If your `module` config option is set to `ESNext`, you might be trying to use ES Modules in Node.

#### Why doesn't `ESNext` work?

`ESNext` doesn't work for the _opposite_ reason `commonjs` doesn't work - it doesn't respect the difference between `.mts` and `.cts` files.

`NodeNext` respects the difference between `.mts` and `.cts` files and emits the correct code for each.

### Solution 2

If you want to emit ES Modules for Node, there's a better way.

1. Set `module` to `NodeNext`

```json
{
  "compilerOptions": {
    "module": "NodeNext",
    "moduleResolution": "NodeNext"
  }
}
```

2. Add `"type": "module"` to your `package.json`

```json
{
  "type": "module"
}
```

Now, your emitted code will be ES Modules, and your `package.json` will be set up correctly.

## I'm Not Transpiling With `tsc`

If you're using a bundler like `esbuild`, `swc`, `vite`, or your framework of choice handles it, this is the section for you.

If you're not sure, check if your `tsconfig.json` has `noEmit: true` in it. If it does, you're _not_ bundling with TypeScript.

### You're Using The Wrong `moduleResolution`

If you're not bundling with TypeScript, you should be using `moduleResolution: "bundler"` and `module: "ESNext"`:

```json
{
  "compilerOptions": {
    "module": "ESNext",
    "moduleResolution": "bundler"
  }
}
```

`moduleResolution: "bundler"` is designed for situations where TypeScript is not responsible for emitting code. It tells TypeScript to assume that the bundler will handle emitting modules.

`module: "ESNext"` is required with `moduleResolution: "bundler"` because it most closely matches the assumptions most bundlers make about your TypeScript code.


Option 'module' must be set to 'NodeNext'

Mapped types are a feature in TypeScript which allow you to map over a union of types to create a new type.

The syntax looks like this:

```typescript
type Fruit = "apple" | "banana" | "orange";

type NewType = {
  [F in Fruit]: {
    name: F;
  };
};
/**
 * {
 *   apple: { name: "apple" };
 *   banana: { name: "banana" };
 *   orange: { name: "orange" };
 * }
 */
```

Let's break down each piece of syntax we're seeing here. The `F in Fruit` acts as a kind of index signature, which allows us to loop over each member of the `Fruit` union. You can think of this as being similar to a JavaScript `for...of` loop:

```typescript
const fruit = ["apple", "banana", "orange"];

for (const f of fruit) {
  console.log(f);
}
```

In both cases, we get a very important thing: a closure over the current thing we're iterating over. In the JavaScript example, we get the current item. In the TypeScript example, we get the current member of the union.

This ability to cleanly map over each member of a union in a simple `for...of` model is what makes mapped types so powerful.

## With `keyof`

Using the `keyof` operator with mapped types gives you a smooth API to create object types _from_ other object types.

```typescript
interface Person {
  name: string;
  age: number;
}

type NullablePerson = {
  [P in keyof Person]: Person[P] | null;
};

/**
 * {
 *   name: string | null;
 *   age: number | null;
 * }
 */
```

Here, we gain access to `P`, which represents either `name` the first time this is iterated over, then `age` the second time. This means we can gain access to the type of each property's value in `Person` by using `Person[P]`.

We can then use this to create a new type that has the same keys and values as `Person` but with each property being nullable.

## Mapping non-string unions with `as`

Sometimes, you'll have a union of things which can't be assigned to the key of an object. For instance, a union of objects:

```typescript
type Event =
  | {
      type: "click";
      x: number;
      y: number;
    }
  | {
      type: "hover";
      element: HTMLElement;
    };
```

Here, you can see that `Event` is a union of two objects. If we tried to do `[E in Event]`, we'd get an error:

```typescript
type EventMap = {
  // Type 'Event' is not assignable to type 'string | number | symbol'.
  [E in Event]: (event: E) => void;
};
```

To get around this, we can use the `as` keyword to tell TypeScript that we want to use the `type` property of each `E` as we iterate over it:

```typescript
type EventMap = {
  [E in Event as E["type"]]: (event: E) => void;
};

/**
 * {
 *   click: (event: { type: "click"; x: number; y: number; }) => void;
 *   hover: (event: { type: "hover"; element: HTMLElement; }) => void;
 * }
 */
```


Mapped Types

## Quick Explanation

- `.mjs` and `.cjs` are a way to tell Node.js explicitly how to interpret your JavaScript files.

- If you're using CommonJS modules with `require`, you should use `.cjs`.

- If you're using ES modules with `import`, you should use `.mjs`.

- `.mts` and `.cts` are TypeScript-specific extensions that tell TypeScript what to compile that specific file down to.

- There are also versions of these extensions that are designed to contain jsx: `.mjsx`, `.cjsx`, `.mtsx`, and `.ctsx`.

- By default, `.js` files will be considered as CommonJS modules. This changes if you set `"type": "module"` in your `package.json` file.

- When using TypeScript, you'll need to import code using the _JAVASCRIPT_ version of the file extension.

```ts
// importing from foo.mts
import { foo } from "./foo.mjs";

// importing from bar.cts
import { bar } from "./bar.cjs";

// importing from baz.js
import { baz } from "./baz.js";
```

- If you're planning to make use of this, you should set `module: "NodeNext"` and `moduleResolution: "NodeNext"` in your `tsconfig.json` file. This will make TypeScript respect the `.mts` and `.cts` extensions.

```json
{
  "compilerOptions": {
    "module": "NodeNext",
    "moduleResolution": "NodeNext"
  }
}
```

- If you want TypeScript to ensure you use the correct module syntax, you can set `verbatimModuleSyntax: true` in your `tsconfig.json` file. This will make TypeScript throw an error if you use the wrong module syntax.

```json
{
  "compilerOptions": {
    "verbatimModuleSyntax": true
  }
}
```

- When `verbatimModuleSyntax` is set to `true`, you'll need to use TypeScript's version of CommonJS imports and exports in your `.cts` files:

```ts
import { foo } = require("./foo.cjs");

const example = 123;

export = example;
```


What are .mjs, .cjs, .mts, and .cts extensions?

`ComponentProps<T>` is a type helper in React that allows developers to extend third-party and DOM elements with additional props.

## Importing

You can either import it from `react` itself:

```tsx
import { ComponentProps } from "react";
```

Or, grab it off the `React` namespace itself.

```tsx
import React from "react";

type Example = React.ComponentProps<"div">;
```

## Use Cases

### Extending DOM Elements

```typescript
type ButtonProps = React.ComponentProps<"div">;
```

You can use `ComponentProps` to extend DOM elements. This is useful when creating custom components that inherit basic properties from native elements.

For instance:

```tsx
type CustomProps {
  text: string;
}

const Div = ({
  text,
  ...props
}: CustomProps &
  React.ComponentProps<"div">) => {
  // Access text here
  return <div {...props}></div>;
};
```

In this example, the CustomProps type defines a single custom prop, text. The `ComponentProps<T>` helper extends the props of the `div` element with any additional props passed to our custom `Div`.

An alternative approach is to use an interface to extend the native component:

```tsx
interface CustomProps
  extends React.ComponentProps<"div"> {
  text: string;
}

const Div = ({ text, ...props }: CustomProps) => {
  // Access text here
  return <div {...props}></div>;
};
```

In this approach, the CustomProps type extends the props of the `div` element, with the additional definition of a `text` prop. The spread operator passes all props, including the text prop, to the `Div` component.

### Extending Third-Party Components

Another use case for `ComponentProps<T>` is to extend third-party components with custom props. This can be useful when you need to extend a third-party component, but they don't expose the necessary types themselves.

```tsx
import ThirdPartyComponent from "third-party";

type CustomProps {
  foo: string;
  bar: number;
}

const MyComponent = ({
  foo,
  bar,
  ...props
}: CustomProps &
  React.ComponentProps<
    typeof ThirdPartyComponent
  >) => {
  // use foo and bar here as needed
  return <ThirdPartyComponent {...props} />;
};
```

In this example, the `CustomProps` type defines two custom props, `foo` and `bar`. The `ComponentProps<T>` helper grabs the props of the `ThirdPartyComponent` component, then we use the `&` intersection to add our `CustomProps`.

Of course, if the library _does_ expose the correct types, it's often worth using those instead:

```tsx
import ThirdPartyComponent, {
  ThirdPartyComponentProps,
} from "third-party";

type CustomProps {
  foo: string;
  bar: number;
}

const MyComponent = ({
  foo,
  bar,
  ...props
}: CustomProps &
  ThirdPartyComponentProps) => {
  return <ThirdPartyComponent {...props} />;
};
```

But in cases where they don't, `ComponentProps<T>` can be a useful escape hatch.

## ComponentPropsWithRef

If you need to also extract the type of the component's `ref`, you can use `React.ComponentPropsWithRef<T>`. For instance:

```tsx
// | ((instance: HTMLButtonElement | null) => void)
// | React.RefObject<HTMLButtonElement>
// | null
// | undefined
type ButtonRef =
  React.ComponentPropsWithRef<"button">["ref"];
```

This resolves into a pretty complicated type - but it represents anything that can be passed into a `<button>`'s ref.


React `ComponentProps<T>` Type Helper

A type helper is a type that can accept other types as arguments. It's like a function, but for types. `Record` is a great example:

```typescript
type MyObj = Record<string, string>;

const obj: MyObj = {};

obj.foo = "bar";

obj[1] = "baz"; // Error: Type 'number' is not assignable to type 'string'.
```

Here, we are defining a type `MyObj` that is an object with string keys and string values. We pass in the types `string` and `string` as arguments to the `Record` type helper, and it returns a new type we can use in our applications.

The syntax might look a bit unusual. But it's just like a function, only that it operates on types instead of values. Instead of `()`, we use `<>`.

## Built-In Utility Types

TypeScript comes with a number of built-in utility types that can be used to create and manipulate types. These are globally available throughout your project - no need to import them. Some of the most commonly used ones include:

- `Partial<T>`: Creates a type with all properties of another type set to optional.
- `Pick<T, K>`: Creates a new type by picking a set of properties `K` from another type `T`.
- `Required<T>`: Creates a type with all properties of another type set to required.
- `Readonly<T>`: Creates a type with all properties of another type set to readonly.

## Building Your Own Custom Type Helpers

You'll often need to build your own type helpers for your project. Let's imagine you have lots of values in your app that might be _something_ or `null` or `undefined`. You could keep writing `string` | `null` | `undefined` everywhere, but that would be tedious and error-prone. Instead, you can create a custom type helper:

```typescript
type Maybe<T> = T | null | undefined;
```

Here, we are defining a custom type helper `Maybe` that takes a type `T` as a parameter and returns a new type that can either be `T`, `null`, or `undefined`.

We can use it like so:

```typescript
interface User {
  id: string;
  name: string;
  phoneNumber: Maybe<string>;
}
```


Type Helpers

`@ts-expect-error` lets you specify that an error _will_ occur on the next line of the file.

Without `@ts-expect-error`, this line of code errors:

```typescript twoslash
// @errors: 2322
const x: string = 12;
```

But with it, it quietens the error:

```typescript twoslash
// @ts-expect-error
const x: string = 12;
```

## Fixing the 'Unused `@ts-expect-error` directive' error

In fact, if `@ts-expect-error` _doesn't_ find an error, it will source an error itself:

```typescript twoslash
// @errors: 2578
// @ts-expect-error
```

This is helpful because it lets us use `@ts-expect-error` to [test our types](/how-to-test-your-types) by letting us be _sure_ that an error will occur.

## Including a description with `@ts-expect-error`

You might also run into this error:

> "Include a description after the `@ts-expect-error` directive to explain why the `@ts-expect-error` is necessary. The description must be 3 characters or longer."

This comes from a [TypeScript ESLint rule](https://typescript-eslint.io/rules/ban-ts-comment). It exists to force you to _explain_ why you're using expecting an error.

Imagine a line of code like this:

```typescript twoslash
const expectsString = (x: string) => {};

// ---cut---

// @ts-expect-error
expectsString(123);
```

It's not clear why we're passing this piece of code a number. Is it a mistake? Is it intentional? If it's intentional, why?

Adding a description to the `@ts-expect-error` directive helps us explain why we're expecting an error:

```typescript twoslash
const expectsString = (x: string) => {};

// ---cut---

// @ts-expect-error: Should expect string
expectsString(123);
```

## Descriptions aren't perfect

Though it's important to note that description doesn't help TypeScript narrow what the error is at all. We might be generating an error we didn't expect, such as misspelling the function:

```typescript twoslash
const expectsstring = (x: string) => {};

// @errors: 2552
expectsString(123);
```

In fact, there's no native way in TypeScript that you can narrow down the exact error thrown by a line of code. So, using `@ts-expect-error` with a loose description is your best bet.

## `@ts-expect-error` or `@ts-ignore`?

When you actually want to ignore an error, you'll be tempted to use `@ts-ignore`. It works similarly to `@ts-expect-error`, except for one thing: it won't error if it _doesn't_ find an error:

```typescript twoslash
// @ts-ignore
const x: string = 12;
```

Sometimes, you'll want to ignore an error that later down the line gets fixed. If you're using `@ts-ignore`, it'll just ignore the fact that the error is gone.

But with `@ts-expect-error`, you'll actually get a hint that the directive is now safe to remove. So if you're choosing between them, pick `@ts-expect-error`.


How to use @ts-expect-error

> Property 'x' does not exist on type 'y'.

This is an extremely common error in TypeScript, so it's important that you understand what it means.

## Quick Explanation

This error is probably occurring because you're trying to access, modify, or delete a property that TypeScript doesn't think is on the object.

```ts twoslash
// @errors: 2339
const example = {};

// Can't access it
example.doesntExist;

// Can't modify it
example.doesntExist = 1;

// Can't delete it
delete example.doesntExist;
```

The reason this happens is that TypeScript thinks your object has a certain shape. If you try to access a property on it that doesn't exist, TypeScript is pretty sure that you've made an error.

It might strike you as odd. The following code won't throw an error at runtime, but TypeScript will give you a big red line:

```ts twoslash
// @errors: 2339
const example = {};

const result = example.doesntExist;
```

This falls into the category of "TypeScript being helpful". TypeScript is pretty sure you've made a mistake, so it's trying to help you out.

So, onto the solutions.

## Solution 1: Is it a typo?

You might have accidentally made a typo in the property name. These can be extremely subtle:

```ts twoslash
// @errors: 2551
type MyUser = {
  fullName: string;
};

const getUserName = (user: MyUser) => {
  return user.fullname;
};
```

If so, use autocomplete on the object you're trying to access to see what properties are available. That's a surefire way to avoid these kinds of issues in the future.

## Solution 2: Widen the type

You might be more sure than TypeScript that the property exists. In that case, you can add it as an optional property to the object you're manipulating:

```ts twoslash
const example: {
  doesntExist?: number;
} = {};

example.doesntExist = 1;

example.doesntExist;
```

TypeScript can't figure out from you assigning `doesntExist` to `1` that it should be a number, so it's important that you tell it via a type annotation.

## Solution 3: Use a Record type

If you're trying to create an object with a dynamic key, you can use a `Record` type to tell TypeScript that the object has a dynamic key:

```ts twoslash
const example: Record<string, number> = {};

example.doesntExist = 1;

example.doesntExist;
```

This is a great way to avoid this error and is great for creating object maps and dictionaries.


Property 'X' does not exist on type 'Y'

In TypeScript, object types let you define the shape of an object. Alongside `string`, `number` and `boolean`, it's one of the most commonly used annotations in a TypeScript codebase. There are three main ways they're declared.

The first is to use the `interface` keyword:

```typescript
interface User {
  name: string;
  age: number;
  email: string;
}
```

In this example, `User` is an object type with three properties: `name`, `age`, and `email`. You can also define an object type inline:

```typescript
function printUser(user: {
  name: string;
  age: number;
  email: string;
}) {
  console.log(`Name: ${user.name}`);
  console.log(`Age: ${user.age}`);
  console.log(`Email: ${user.email}`);
}
```

In this example, the `printUser` function accepts an object with three properties: `name`, `age`, and `email`. This is equivalent to the `User` interface defined above.

You can also use the `type` keyword:

```typescript
type User = {
  name: string;
  age: number;
  email: string;
};
```

Defining object types will give you a few different kinds of safety. It'll prevent you from passing objects with incorrectly typed or missing properties:

```typescript
const printUser = (user: User) => {};

printUser({
  name: "John Doe",
  age: 42,
}); // Type error - email is missing!

printUser({
  name: "John Doe",
  age: "42",
  email: "john@doe.com",
}); // Type error - age is the wrong type!
```

It'll also give you type safety (and autocomplete!) when accessing properties on objects:

```typescript
const printUser = (user: User) => {
  user.doesNotExist; // doesNotExist is not a property on User!
};
```


Object Types

- `as const` can be used to mark a value as deeply readonly - i.e., it can't be mutated in any way.

- It's different from `Object.freeze` in two ways. First, it only runs at compile-time, so it disappears at runtime. Second, `Object.freeze` only works on the top level. `as const` works on the entire object.

```ts twoslash
// @errors: 2540
const obj = {
  foo: {
    bar: 42,
  },
} as const;

// Error!
obj.foo.bar = 43;

const freezedObj = Object.freeze({
  foo: {
    bar: 42,
  },
});

// Works!
freezedObj.foo.bar = 43;
```

- It's useful on objects, but can also be used on arrays to turn them into readonly tuples:

```ts twoslash
// @errors: 2339
const arr = [1, 2, 3] as const;

arr.push(4);
```

- Objects and arrays marked with `as const` get inferred as their literal types, not the wider types. This can be useful for creating type-safe enums without needing the `enum` keyword.

```ts twoslash
const obj = {
  foo: {
    bar: 42,
  },
};

// Inferred as number
console.log(obj.foo.bar);
//                  ^?

const obj2 = {
  foo: {
    bar: 42,
  },
} as const;

// Inferred as its literal!
console.log(obj2.foo.bar);
//                   ^?
```

- `as const` can also be used to force values to infer as narrowly as possible - for instance, inside objects:

```ts twoslash
const buttonProps = {
  type: "button" as const,
  onClick: () => {
    console.log("clicked");
  },
} as const;

// Inferred as "button", not string
console.log(buttonProps.type);
//                        ^?
```

- It can also be used to encourage a function that returns an array to infer as a tuple:

```ts twoslash
declare const useState: () => [
  string,
  (newState: string) => void
];

const useStateWrapped = () => {
  const [state, setState] = useState();

  return [state, setState] as const;
};
```


'as const' Annotations

> Element implicitly has an 'any' type because expression of type 'X' can't be used to index type 'Y'.

This error is likely occurring because you're trying to use a type that's too loose to access an object's properties.

```typescript twoslash
// @errors: 7053
const myObj = {
  a: 1,
  b: 2,
};

const access = (str: string) => {
  return myObj[str];
};
```

## Solution 1: Tighten the index

One solution is to try to make the type doing the indexing tighter. In this case, by changing `str` to `keyof typeof myObj`:

```typescript twoslash
const myObj = {
  a: 1,
  b: 2,
};

// ---cut---
const access = (str: keyof typeof myObj) => {
  return myObj[str];
};
```

This is very safe because it ensures that the string you're using to index into the object is one of the keys of the object. But it's not always possible.

## Solution 2: Loosen the object type

When you declare an object, TypeScript will try to infer the most specific type possible. In this case, it's inferring that `myObj` is an object with two properties, `a` and `b`, whose values are numbers.

If you want to loosen the type of the object, you can do so by adding a type annotation:

```typescript twoslash
const myObj: Record<string, number> = {
  a: 1,
  b: 2,
};
```

Now, we can access the object with any string - and also add any string to the object:

```typescript twoslash
const myObj: Record<string, number> = {
  a: 1,
  b: 2,
};

// ---cut---

// We can add new keys to the object!
myObj["c"] = 3;

const access = (str: string) => {
  // Accessing with string is perfectly OK!
  return myObj[str];
};
```

Note that if you choose this approach, you should add [`noUncheckedIndexedAccess`](https://www.totaltypescript.com/tips/make-accessing-objects-safer-by-enabling-nouncheckedindexedaccess-in-tsconfig) to your tsconfig, which will give you extra safety when accessing the object.

## Solution 3: Cast the index

Finally, you can do a cast inside the access itself:

```typescript twoslash
const myObj = {
  a: 1,
  b: 2,
};

// ---cut---

const access = (str: string) => {
  return myObj[str as keyof typeof myObj];
};
```

This is slightly less safe and might result in an unexpected result because we're fooling TypeScript into thinking that `myObj[str]` will always return a `number`. But if we call `access` with `c`, we won't get a number back at runtime:

```typescript twoslash
const myObj = {
  a: 1,
  b: 2,
};

const access = (str: string) => {
  return myObj[str as keyof typeof myObj];
};

// ---cut---

/**
 * TS things it's a number, but it's actually undefined!
 */
const cResult = access("c");
//    ^?
```

If possible, you should be using solution 1 or 2 instead - but having this cast in your pocket can be useful.


Expression of type string can't be used to index type X

You're likely here because you've spotted this error:

> An interface can only extend an object type or intersection of object types with statically known members.

This error can happen because you're trying to extend a union type. For instance, this code will fail:

```ts twoslash
// @errors: 2312
type Example =
  | { a: string }
  | {
      b: string;
    };

interface Foo extends Example {
  c: string;
}
```

This is an error because interfaces can't extend union types. [Interfaces can't represent unions](/type-vs-interface-which-should-you-use), so it's not possible to create one using the `extends` keyword.

Instead, you can use an intersection type instead of `extends`:

```ts twoslash
type Example =
  | { a: string }
  | {
      b: string;
    };

type Foo = Example & {
  c: string;
};
```

Now, you'll have what you need - an object where you can either pass in `a` or `b`, but you must always pass in `c`.


Explained: An Interface Can Only Extend an Object Type

In TypeScript, `PropertyKey` is a global type in TypeScript that represents the data type of a property key. It can be a `string`, a `symbol`, or a `number`.

You don't need to import it into your project - it's available globally.

```typescript
// string | number | symbol
type Example = PropertyKey;
```

This can be useful in a sticky situation where you want to create record types with all possible keys:

```typescript
type RecordWithAllKeys = Record<
  PropertyKey,
  unknown
>;
```


The `PropertyKey` Type

In TypeScript, literal types let you create types that express specific values.

For instance, let's say you only wanted to accept `success` or `failure` in a function argument. You could use `string`:

```typescript
function printStatus(status: string) {
  console.log(`Status is: ${status}`);
}

printStatus("error"); // No type error!
```

But as you can see, we can call `printStatus` with any `string` value, which is not what we want.

Instead, we can use a literal type:

```typescript
function printStatus(
  status: "success" | "failure"
) {
  console.log(`Status is: ${status}`);
}

printStatus("success"); // Outputs: Status is: success
printStatus("error"); // Type error!
```

Now, we can only call `printStatus` with the values `success` or `failure`.

We can also use literal types with other basic types:

```typescript
// Numeric literals
type ValidIndexes = 1 | 2 | 3 | 4 | 5;

// Boolean literals
type SuccessState = {
  success: true;
  data: string;
};

type FailureState = {
  success: false;
  error: string;
};
```

In the example above, `ValidIndexes` can only be `1`, `2`, `3`, `4`, or `5`. `SuccessState` can only be `{ success: true, data: string }`, and `FailureState` can only be `{ success: false, error: string }`.


Literal Types

The `any` type in TypeScript is a workaround for cases when you don't know what type a value might be. It allows you to assign a variable or function parameter to be of literally any type.

Here's an example of using `any` in a function argument:

```typescript
function greet(name: any) {
  console.log(`Hello, ${name}!`);
}

greet("John"); // Outputs: Hello, John!
greet(123); // Outputs: Hello, 123!
```

`any` lets you do extremely dangerous things in TypeScript. By marking a variable as `any`, you're telling the compiler to ignore any type errors that might occur.

```typescript
const user: any = {
  name: "John",
  age: 30,
};

user.roles.push("admin"); // Runtime error!
```

In the example above, we're trying to push a new value to the `roles` array, but the `roles` property doesn't exist on the `user` object. This will cause a runtime error, but TypeScript won't warn us about it because we've marked the `user` variable as `any`.

## `any` vs `unknown`

The `unknown` type is a type-safe counterpart of `any`, which requires you to perform a type check before using the variable. Unlike `any`, `unknown` can help prevent runtime errors by forcing you to narrow down the type of the variable before using it in your code.

Here's an example of using `unknown` in a function argument:

```typescript
function greet(name: unknown) {
  if (typeof name === "string") {
    console.log(`Hello, ${name}!`);
  }
}

greet("John"); // Outputs: Hello, John!
greet(123); // No output
```

Overall, the `any` type can be useful in situations where you need more flexibility, but it comes with the cost of losing type safety. It's best to use it sparingly and with caution.


The `any` type

## Quick Explanation

> Object is of type 'unknown'.

This error is probably occurring because you're trying to access a property on something marked as `unknown` before narrowing it. You should either narrow it, or use a type assertion.

This is extremely common in `try`/`catch` blocks:

```ts twoslash
// @errors: 18046
try {
  // some code
} catch (e) {
  console.log(e.message);
}
```

This is happening because `unknown` is considered to be _any_ possible type. It's different from `any` because you can't access any properties on it without narrowing it first. With `any`, you can access any property on it _without_ narrowing it.

## Solution 1: Narrow the type

The first option is to narrow the type. You can do this by checking if the property exists on the object:

```ts twoslash
try {
  // some code
} catch (e) {
  if (
    typeof e === "object" &&
    e &&
    "message" in e &&
    typeof e.message === "string"
  ) {
    // message gets narrowed to string!
    console.log(e.message);
    //            ^?
  }
}
```

We first check if `e` is an `object`. Then, we check if it's not `null` or `undefined`. Then, we check if it has a `message` property. Finally, we check if `e.message` is a `string`.

TypeScript is smart enough to follow along with this logic and narrow `e.message` to a `string`!

## Solution 2: Narrow the type using `instanceof`

If you're dealing with a class, you can use `instanceof` to narrow the type. This works especially well with errors:

```ts twoslash
try {
  // some code
} catch (e) {
  if (e instanceof Error) {
    // e is narrowed to Error!
    console.log(e.message);
    //            ^?
  }
}
```

## Solution 3: Use a type predicate

You can wrap your narrowing logic in a custom type predicate:

```ts twoslash
function hasMessage(x: unknown): x is { message: string } {
  return Boolean(
    typeof x === "object" &&
      x &&
      "message" in x &&
      typeof x.message === "string"
  );
}

try {
  // some code
} catch (e) {
  if (hasMessage(e)) {
    // e is narrowed to { message: string }!
    console.log(e.message);
    //            ^?
  }
}
```

This is useful if you want to reuse the same logic in multiple places.

## Solution 4: Use a type assertion

If you're sure that the type is correct, you can use a type assertion to tell TypeScript that it's correct:

```ts twoslash
try {
  // some code
} catch (e) {
  console.log((e as Error).message);
}
```

This is the least type-safe option, but it's also the easiest to use. Just be careful that you're not asserting the wrong type!


Object is of type 'unknown'

In TypeScript, union types let you express types that could be one of several different things.

Here's an example of a union type in a function argument:

```typescript
function printId(id: string | number) {
  console.log(`ID is: ${id}`);
}

printId("abc"); // Outputs: ID is: abc
printId(123); // Outputs: ID is: 123
```

In the example above, the `id` parameter can be either a `string` or a `number`.

Union types can be used with any type, including literals:

```typescript
type Status = "success" | "failure";

function printStatus(status: Status) {
  console.log(`Status is: ${status}`);
}

printStatus("success"); // Outputs: Status is: success
printStatus("error"); // Type error!
```

As you can see, union types provide a level of type safety that `any` type lacks. It prevents errors at compile-time, reducing the chances of runtime issues.

You can include as many members as you want in a union type:

```typescript
type MassiveUnionType =
  | "animal"
  | {
      whatever: string;
    }
  | boolean
  | (() => void)
  | 100
  | "other string";
```

## Examples of Union Types

Here's a list of things you could use union types for in TypeScript:

```typescript
type HTTPRequestMethods =
  | "GET"
  | "POST"
  | "PUT"
  | "DELETE";
```

```typescript
type CSSLengthUnits =
  | "em"
  | "ex"
  | "ch"
  | "rem"
  | "vw"
  | "vh"
  | "vmin"
  | "vmax"
  | "px"
  | "cm"
  | "mm"
  | "in"
  | "pt"
  | "pc";
```

```typescript
type UserRoles =
  | "admin"
  | "editor"
  | "contributor"
  | "subscriber";
```

```typescript
type PaymentMethods =
  | "credit_card"
  | "debit_card"
  | "paypal"
  | "bank_transfer";
```

```typescript
type HTTPResponseStatusCodes =
  | 200
  | 201
  | 400
  | 401
  | 403
  | 404
  | 500;
```

```typescript
type NavigationalDirections =
  | "north"
  | "south"
  | "east"
  | "west";
```

```typescript
type SocialMediaButtonsIcons =
  | "facebook"
  | "twitter"
  | "instagram"
  | "pinterest"
  | "linkedin";
```

```typescript
type TimeZones =
  | "GMT"
  | "EST"
  | "CST"
  | "PST"
  | "JST"
  | "AEST"
  | "CET"
  | "EET"
  | "IST";
```


The Prettify Helper