The satisfies keyword is quite different than "as const." What it does is:

1. Enforce that a value adheres to a specific type

2. But, doesn't cause the value to be cast to that type.

For example, if you have a Rect type like:

    type Rect = { w: number, h: number }

You might want to enforce that some value satisfies Rect properties... But also allow it to have others. For example:

    const a = { x: 0, y: 0, w: 5, h: 5 };

If you wrote it as:

    const a: Rect = // ...

TypeScript wouldn't allow you to also give it x and y properties. And if you did:

    as Rect

at the end of the line, TypeScript would allow the x, y properties, but would immediately lose track of them and not allow you to use them later, because you cast it to the Rect type which lacks those properties. You could write an extra utility type:

    type Location = { x: number, y: number };
    const a: Location & Rect = // ...

But that can get quite verbose as you add more fields. And besides: in this example, all we actually are trying to enforce is that the object is a Rect — why do we also have to enforce other things at the same time? Usually TS allows type inference for fields, but here, as soon as you start trying to enforce one kind of shape, suddenly type inference breaks for every other field.

The satisfies keyword does what you want in this case: it enforces the object conforms to the type, without casting it to the type.

    const a = { x: 0, y: 0, w: 5, h: 5 } satisfies Rect;
    // a.x works

Then if someone edits the code to:

    const a = { x: 0, y: 0, width: 5, height: 5 } satisfies Rect;

TypeScript will throw an error, since it no longer satisfies the Rect type (which wants h and w, not height and width).

▲ RHSeeger 8 hours ago | parent | next [-]

This was a fantastic writeup, thanks. If you don't mind an additional question...

How does this work,

    function coolPeopleOnly(person: Person & { isCool: true }) {
        // only cool people can enter here
    }

    const person = {
        name: "Jerred",
       isCool: true,
    } satisfies Person;

    coolPeopleOnly(person);

Since

- person isn't const, so person.isCool could be mutated

- coolPeopleOnly requires that it's input mean not only Person, but isCool = true.

	▲	MrJohz 2 hours ago \| parent [-]
		If you ignore the `satisfies` for a moment, the type of `person` is the literal object type that you've written (so in this case, { "person": string, isCool: true }). So coolPeopleOnly(person) works, regardless of whether `satisfies` is there, because TypeScript sees an object literal that has all the person attributes and also `isCool: true`. (You could mutate it to `isCool: false` later, but then TypeScript would complain because `isCool: false` is different to `isCool: true`. When that happens isn't always obvious, TypeScript uses a bunch of heuristics to decide when to narrow a type down to the literal value (e.g. `true` or `"Jerred"`), vs when to keep it as the more general type (e.g. `boolean` or `string`).) What `satisfies` is doing here is adding an extra note to the compiler that says "don't change the type of `person` at all, keep it how it is, _but_ also raise an error if that type doesn't match this other type". (This is only partially true, I believe `satisfies` does affect the heuristics I mentioned above, in that Typescript treats it a little bit like `as const` and narrows types down to their smallest value. But I forget the details of exactly how that works.) So the `coolPeopleOnly` check will pass because the `person` literal has all the right attributes, but also we'll get an error on the literal itself if we forget an attribute that's necessary for the `Person` type.

▲ nixpulvis 9 hours ago | parent | prev | next [-]

Why is satisfies needed at all, when can't. Typescript realize that `a` satisfies `Rect` automatically?

	▲	ameliaquining 9 hours ago \| parent \| next [-]
		It does; the code will still type-check without the satisfies operator. satisfies lets you say "if this value doesn't conform to this type then I want that to be an immediate compile error, even if it would otherwise be okay". Which isn't needed all that often since usually getting the type wrong would produce a compile error elsewhere, but occasionally it proves useful. When designing the feature they collected some use cases: https://github.com/microsoft/TypeScript/issues/47920
	▲	9 hours ago \| parent \| prev [-]
		[deleted]

▲ michaelcampbell 12 hours ago | parent | prev [-]

Thanks; succinct and for me, I understood it.