Til: `satisfies` Is My Favorite Typescript Keyword

TypeScript codebases I've seen generally seem to have the widest demonstration of skill gap versus other languages I use.

For example, I don't ever see anyone using `dynamic` or `object` in C#, but I will often see less skilled developers using `any` and `// @ts-ignore` in TypeScript at every possible opportunity even if it's making their development experience categorically worse.

For these developers, the `type` keyword is totally unknown. They don't know how to make a type, or what `Omit` is, or how to extend a type. Hell, they usually don't even know what a union is. Or generics.

I sometimes think that in trying to just be a superset of JavaScript, and it being constantly advertised as so, TypeScript does not/did not get taken seriously enough as a standalone language because it's far too simple to just slot sloppy JavaScript into TypeScript. TypeScript seems a lot better now of having a more sane tsconfig.json, but it still isn't strict enough by default.

This is a strong contrast with other languages that compile to JavaScript, like https://rescript-lang.org/ which has an example of pattern matching right there on the home page.

Which brings me onto another aspect I don't really like about TypeScript; it's constantly own-goaling itself because of it's "we don't add anything except syntax and types" philosophy. I don't think TypeScript will ever get pattern matching as a result, which is absurd, because it has unions.

    match (x) {
      "bob": ...,
      string: ...,
      () => Promise<void>: ...,
      () => Promise<string>: ...,
    }

Honestly I just use TypeScript to prevent `1 + [] == "1"` and check that functions are called with arguments. I don't care about type theory at all and the whole thing strikes me as programmers larping (poorly) as mathematicians.

    isLoading: boolean
    result: Foo
    hasError: boolean
    errorMessage: string | null

   class LoadingState extends State {}
   class ResultState extends State {}
   class ErrorState extends State {}
   const state: State = new LoadingState

I have mixed feelings about Typescript, I hate reading code with heavy TS annotations because JS formatters are designed to keep line widths short, so you end up with a confusing mess of line breaks. Pure JS is also just more readable.

Also you can so easily go overboard with TS and design all sorts of crazy types and abstractions based on those types that become a net negative in your codebase.

However it does feel really damn nice to have it catch errors and give you great autocomplete and refactoring tooling.

> Too many really stop at the very basics.

I don’t think that means it has a steep learning curve. It just means the basics suffice for a ton of TypeScript deployments. Which I personally don’t see as the end of the world.

> Hell, ask someone to write a signature for array flat, you'd be surprised how many would fail.

To be clear, an array flat type:

    type FlatArr<Arg extends unknown[]> = Arg extends [infer First, ...(infer Rest)] ?
      First extends unknown[] ?
        [...First, ...FlatArr<Rest>] :
        [First, ...FlatArr<Rest>] :
      [];

is far from basic Typescript. The average Typescript dev likely doesn't need to understand recursive conditional types. It's a level of typescript one typically only needs for library development.

Not only have I never been expected to write something like this for actual work, I'm not sure it's been useful when I have, since most of my colleagues consider something like this nerd sniping and avoid touching/using such utilities, even with documentation.

    function flat([head, ...tail]) {
      return Array.isArray(head)
        ? [...flat(head), ...flat(tail)]
        : [head, ...flat(tail)]
    }

    export async function promiseAll<T extends Record<string, Promise<any>>>(promises: T): Promise<{ [K in keyof T]: Awaited<T[K]> }> {
        const keys = Object.keys(promises) as Array<keyof T>;
        const result = await Promise.all(keys.map(key => promises[key]));
        return Object.fromEntries(result.map((value, i) => [keys[i], value])) as { [K in keyof T]: Awaited<T[K]> };

    type Flatten<T> = T extends Array<infer U> ? Flatten<U> : T

  type FlatArray<T extends unknown[]> = Flatten<T[number]>[]

    Flatten<[1,[2,'a',['b']]]>

    const foo: Flatten<[1,[2,'a',['b']]]> = 'b'; // OK
    const bar: Flatten<[1,[2,'a',['b']]]> = 'c'; // Error: Type '"c"' is not assignable to type '1 | 2 | "a" | "b"'

     type Flatten<T> = T extends Array<unknown> ? Flatten<T[number]> : T

    console.log(JSON.stringify([1,[2, [3]]].flat()));
    > [1,2,[3]]

    // 'readonly' added to the 'extends' sections to work on "as const" (readonly) arrays
    type FlatArr<Arg extends unknown[] | readonly unknown[]> = Arg extends readonly [infer First, ...(infer Rest)] ?
      First extends readonly unknown[] ?
        [...First, ...FlatArr<Rest>] :
        [First, ...FlatArr<Rest>] :
      [];

    const flatten = <Arr extends unknown[] | readonly unknown[]>(arr: Arr): FlatArr<Arr> => arr.flat() as FlatArr<Arr>
    const someArr = [1,[2,'a',['b', ['c']]]] as const; // const someArr: readonly [1, readonly [2, "a", readonly ["b", readonly ["c"]]]]
    const someArr2 = flatten(someArr);                 // const someArr2: [1, 2, "a", readonly ["b", readonly ["c"]]]

    

  function flat() {                        // type FlatArr<Arg extends unknown[]> =
      let [first, ...rest] = this;
      return (this.length > 0) ?           // Arg extends [infer First, ...(infer Rest)] ?
          Array.isArray(first) ?           //   First extends unknown[] ?
              [...first, ...flat(rest)] :  //     [...First, ...FlatArr<Rest>] :
              [first, ...flat(rest)] :     //     [First, ...FlatArr<Rest>] :
          [];                              //   [];
  }

  function flat() {
      if (this.length > 0) {
          let [first, ...rest] = this;
          if (Array.isArray(first)) {
              return [...first, ...flat(rest)];
          } else {
              return [first, ...flat(rest)];
          }
      } else {
          return [];
      }
  }

  type FlatArray<Arr, Depth extends number> = {
      done: Arr;
      recur: Arr extends ReadonlyArray<infer InnerArr> ? FlatArray<InnerArr, [-1, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20][Depth]>
          : Arr;
  }[Depth extends -1 ? "done" : "recur"];

  interface ReadonlyArray<T> {
      // [Snipped: flatMap, and flat’s doc comment]
      flat<A, D extends number = 1>(
          this: A,
          depth?: D,
      ): FlatArray<A, D>[];
  }

  // [And repeated for interface Array<T>.]

> Too many really stop at the very basics.

As someone who knows slightly more than the basics, and enough to know about the advanced stuff that I don't know about, this is the correct place to stop.

I would much rather restructure my javascript than do typescript gymnastics to fit it into the type system.

You're right, but that begs the question: does a type system really require such complexity?

I'm aware that type theory is a field in and of itself, with a lot of history and breadth, but do developers really need deep levels of type flexibility for a language to be useful and for the compiler to be helpful?

I think TypeScript encourages "overtyping" to the detriment of legibility and comprehension, even though it is technically gradually typed. Because it is so advanced and Turing complete itself, a lot of brain cycles and discussion is spent on implementing and understanding type definitions. And you're definitely right that it being verbose also doesn't help.

So it's always a bittersweet experience using it. On one hand it's great that we have mostly moved on from dynamically typed JavaScript, but on the other, I wish we had settled on a saner preprocessor / compiler / type system.

typescript is largely a result of solving a non-existent problem. Yeah JS is finicky & has foot-guns, however they're ways around those foot guns that don't involve typescript.

Rich Hickey in 10 Years of Clojure & Maybe Not then the Value of Values - lays this out - though not meant at typescript but static types in general.

the thing most people don't have proper Javascript fundamentals.

Function signatures: JSDoc works

Most types - use Maps | Arrays

if a value doesn't exist in a map we can ignore it. There's also the safe navigation operator.

Instead of mutable objects - there's ways around this too. Negating types again.

> ask someone to write a signature for array flat

Out of curiosity - what do you think is a satisfactory answer here?

My answer would vary wildly based upon more details, but at the most basic all I can think you could guarantee is Array<unknown> => Array<unknown>?

It's also terribly documented. As an example, I don't think `satisfies` is in the docs outside of release notes. There's lots more stuff like that, which makes using it kind of frustrating.

"There basics," well understood and judiciously applied, is where the bulk of TypeScript's value lies.

Not steep so much as deep.

There’s a lot you can do in TypeScript. But you don’t have to do it. And TS existed successfully a long time without those features.

to our defense, we want to build stuff not become ts wizards. also I've worked with libraries with heavy heavy typing that it was a nightmare if you wanted to use their lib in any other way than what they have imagined.

This is the bell curve meme, and you are in the middle telling us "template metaprogramming in C++ is amazing".

these are things most developers don't know how to do in most language's type systems. I think only rust with its focus on functional roots has seen similar focus on utilizing its type system to its fullest extent.

Being a JS/TS one-trick pony all my career, how does it compare to other languages? I don't really see much difference, except if comparing with some C++ shenanigans.

>And even though I consider myself okay at TypeScript, the gap with the more skilled of my colleagues is still impressively huge.

Maybe they're smart, but the even smarter dev would avoid unnecessary complexity in the first place.

Typescript types often devolve into

keyof typeof[number] ? uppercase (myNum)

On the other hand, there isn't much Omit, readonly, mutable in existing code bases, so devs have nowhere to learn but documentation.

Then the ground shifts again and –what should be basic stuff – enums are banned, because erasableSyntaxOnly makes life so much easier.

I stopped doing anything advance because I realized nobody actually wanted to do all of the advanced stuff. None of the NPM community does anything more than the basics.

Frankly, I prefer it that way. A lot of the advance stuff doesn’t actually enable any new functionality. It only shortens the code paths for implementing.

> The average multi-year TypeScript developer I meet can barely write a basic utility type, let alone has any general (non TypeScript related) notion of cardinality or sub typing. Hell, ask someone to write a signature for array flat, you'd be surprised how many would fail.

I think you're both exaggerating your blanket accusations of incompetence and confusing learning curve with mastering extremely niche techniques akin to language gotchas.

Can you even do that? I though you could only enterprise in secure languages, like Java

When you are building even moderately large non-trivial real world software with JS, you would thank your stars that TS exists and that it has features like this. It's amazing how quickly the basic concepts of software engineering become inadequate when they run up against the real world.

For example, a naive engineer might think, ah, databases have this oFFSET clause, good, I'll use, unaware that is a foot gun for real world performance.

Or they may think the DELETE operation on DBs is a normal thing, unaware that in most cases it should NOT be used at all.

Or they might think loops are idiomatic, unaware that when you are writing large software you should and can probably almost eliminate loops (unless you are using a DSL like SQL extensions, config languages, etc)

Or they may be unaware of the thorny issues around queues (or even why they might be necessary in the first place) and concurrent access to data.

Or they might not understand why the dogma of separating content and presentation is nonsensical in many situations.

Etc.

You can do that with assembly and not know ANY high level language.

You might be interested in reading PG's treatise on "the blub paradox".

I think this is spot on. TS goes very very far without the gymnastics. Its good to know these things, but not even close to necessary to be productive. Not to mention IDE support for TS is on a very different level conpared to the shitshow that is Javascript.

Also, Angular dev spotted :)

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).

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

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

    coolPeopleOnly(person);

I've really only found benefit on the return type of functions, when you can say that a type parameter satisfies a type (with the return type being a boolean). This let's you use `if (isPerson(foo))` and typescript will narrow the type appropriately in the conditional

With as const you can’t verify against another interface

Then either make the properties optional or use Partial on the type you are satisfying

You can sorta think of `satisfies Foo` as "the type is exactly the literal value, but also make sure the value could be used in the place of a Foo"

The author gets into that. `Thetype` might be complex. It also protects you from overgeneralizing, like casting to and from `unknown` to escape the type checker.

    type Current = {
      kind: "ac" | "dc";
      amps: number;
    }
    
    type Dc = {
      kind: "dc";
      amps: number;
    }
    
    const ac: Current = {
      kind: "ac",
      amps: 10000000,
    }
    
    const handleDc = (thing: Dc) => {}
    
    const badConvert = (c: Current) => ({...c, kind: "dc"});
    
    /**
    * Argument of type '{ kind: string; amps: number; }' is not assignable to parameter of type 'Dc'.
        Types of property 'kind' are incompatible.
            Type 'string' is not assignable to type '"dc"'.(2345)
    */
    handleDc(badConvert(ac));
    
    const goodConvert = (c: Current) => ({
      ...c, kind: "dc",
    } satisfies Dc);
    
    handleDc(goodConvert(ac));
    
    /**
    * Object literal may only specify known properties, and 'bar' does not exist in type 'Dc'.
    */
    const badConvert2 = (c: Current) => ({
      ...c, kind: "dc", bar: "qwerty"
    } satisfies Dc);

   type Current = { amps: number; };
   type Ac = { kind: "ac" } & Current;
   type Dc = { kind: "dc" } & current;
   const currentToDc = (c: Current): Dc => ...
   const acToDc = (c: Ac): Dc => ...

Because what you wrote broadens the type. `satisfies` validates the type without broadening it.

const c: string = 'c';

This will be of type string instead of type 'c'. This is a barebones example and it already breaks support for template literal types. Imagine how much better `satisfies` is for complex union types.

Yeah, I believe that doesn't quite work correctly for nullable fields or cases where the Zod type would be a subtype of the declared type. But it's a really useful technique, because it's a lot easier to work with types you've declared in TypeScript than the ones Zod generates. I'm sure there's scope for a validation library that is designed around the user providing a TypeScript type and then producing an error if the validation doesn't match that type.

This thread is weird, also spot on, not sure why its downvoted. I am happy when the IDE spots my dufusness.

That's a little ungenerous. Richer types are not intrinsically about metaprogramming, they just let you model your domain more accurately so you can turn runtime errors into build-time errors. If your system already has natural constraints, you get to document them in a machine-checkable way.

It prevents you from mutating via the reference that you obtain from `satisfies` without casting its type, yes (or rather more precisely, you can mutate it, but only to the one allowed value).

However, the object can still be mutated via other references to it. TypeScript is full of holes like this in the type system - the problem is that they are trying to bolt types and immutability onto a hot mess that is JS data model while preserving backwards compatibility.

Nice. I didn’t know I can now replace my “assertExhaustive” function.

Previously you could define a function that accepted never and throws. It tells the compiler that you expect the code path to be exhaustive and fixes any return value expected errors. If the type is changed so that it’s no longer exhaustive it will fail to compile and (still better than satisfies) if an invalid value is passed at runtime it will throw.

I generally do this via a `throw UnsupportedValueError(value)`, where the exception constructor only accepts a `never`. That way I have both a compile time check as well as an error at runtime, if anything weird happens and there's an unexpected value.

  // eslint-disable-next-line @typescript-eslint/restrict-template-expressions

  throw new Error(`Unexpected object: ${x}`)

https://typescript-eslint.io/rules/switch-exhaustiveness-che... if that is something you're not aware of!