Extreme explorations of TypeScript's type system

[fishtoaster]

You can do some truly silly things with sufficiently ridiculous uses of typescript. I built a typecheck-time spell checker[0] in it such that:

  import { ValidWords } from "./spellcheck";
  
  // Typechecks cleanly:
  const result: ValidWords<"the quick brown fox."> = "valid";
  
  // Throws a type error
  const result: ValidWords<"the qxick brown fox."> = "valid";

[0] https://github.com/kkuchta/TSpell

[kretaceous]

Your GitHub account is a rabbit hole of crazy interesting "monstrosities" like this. I love them! My favorite ones, apart from this typechecker, are css-only-chat[1] and tabdb[2]

1: https://github.com/kkuchta/css-only-chat 2: https://github.com/kkuchta/tabdb

[gernb]

so that's great and I know this wasn't your point but ....

I use this VSCode extension

https://marketplace.visualstudio.com/items?itemName=streetsi...

To spell check my code. It's surprisingly useful. It doesn't check at compile time but it does check camelCase and snake_case and even in typescript code I've found it highlight various actual issues.

[joshuakgoldberg]

This is great!

[kevingadd]

When doing fancy things with typescript types, be really careful - it's possible to accidentally construct typescript types that will increase your tsc compile times by multiple seconds and the tooling for troubleshooting this is nonexistent. A tiny change to one codebase I work on made compile times go from 300ms to something like 7 seconds and it took me something like 14 hours of grepping and manually bisecting source code to find the cause - tsc was O(N * N * N) trying all possible types for a string literal to determine whether any of them were valid matches, and someone had defined a very fancy string literal type.

When this happens, typescript language integration (like in vs code or sublime text) will suddenly fall over and stop working correctly, and it'll be near impossible to figure that out too.

Our build uses rollup to invoke tsc and as it happens their profiling system doesn't actually measure how long tsc takes to run - the time is unaccounted :) So in general, be aware that 'typescript is taking a long time to compile' is a blind spot for this whole ecosystem and if you hit it you're going to have to work hard to fix it.

[int_19h]

This doesn't even require a type system anywhere near as fancy as what TS has. C#, for example, has a similar problem with how type inference in lambdas interacts with overload resolution, once you start nesting those lambdas:

https://docs.microsoft.com/en-us/archive/blogs/ericlippert/l...

[dllthomas]

> If you do find a need to use type operations, please—for the sake of any developer who has to read your code, including a future you—try to keep them to a minimum if possible. Use readable names that help readers understand the code as they read it. Leave descriptive comments for anything you think future readers might struggle with.

Also, as you start getting complicated logic in your types, you need to test your types; make sure they admit things they should admit and reject things that they should reject. Ideally these tests can also serve some role as examples for your documentation.

[acemarke]

We do a _lot_ of this in the Redux library repos (examples: [0] [1] [2] ). We have some incredibly complicated types in our libraries, and we have a bunch of type tests to confirm expected behavior.

Generally, these can just be some TS files that get compiled with `tsc`, but it helps to have a bunch of type-level assertions about expected types.

I actually recently gave a talk on "Lessons Learned Maintaining TS Libraries" [3], and had a couple slides covering the value of type tests and some techniques.

[0] Redux Toolkit's `createSlice`: https://github.com/reduxjs/redux-toolkit/blob/9e24958e6146cd...

[1] Reselect's `createSelector`: https://github.com/reduxjs/reselect/blob/f53eb41d76da0ea5897...

[2] React-Redux's `connect`: https://github.com/reduxjs/react-redux/blob/720f0ba79236cdc3...

[3] https://blog.isquaredsoftware.com/2022/05/presentations-ts-l...

[yulaow]

I lost it when at my previous job I found a 20 multiline super complex type defined by another dev, asked him to describe it because I was in a tight deadline and had not time to parse whatever he was defining. He starts with "it's pretty simple" and then used like 10 minutes to describe me what he meant while writing on paper the various pieces getting confused two times. At the end of the day it could be simplified in a one line union type of a few strings which would cover 99% of the usecases and the other 1% was something we had never used and would never use.

I really wish people would focus more on keeping types as simple as possible instead of using that complexity just because the language allowed it.

[brundolf]

@ts-expect-error is useful for this

[flotwig]

There are probably newer tools for this, but we use `eslint-plugin-expect-type` [0] for this:

https://github.com/cypress-io/cypress/blob/develop/cli/types...

[0]: https://github.com/JoshuaKGoldberg/eslint-plugin-expect-type

[sir_pepe]

To try and limit one's use of operations on types, as suggested in the article, is not really great advice in my opinion. Sure, you would not want to actually implement and use a VM in types, but distilling rules about a program into types and then deriving the actual interfaces and signatures from those rules with operations on types? That's quite powerful.

TypeScript's type annotations are really a DSL embedded into JavaScript. And they can, and, depending on the problem at hand, should be treated as such.

[jasonkillian]

> TypeScript's type annotations are really a DSL embedded into JavaScript. And they can, and, depending on the problem at hand, should be treated as such.

I think this is the key. If treated as you describe, meaning the advanced types are well-written, well-documented, and well unit-tested as if they are "true" code, then using them shouldn't be too much of an issue.

However, I think people often just assume that the types aren't "real" code and thus the normal concepts of good software engineering don't apply and type monstrosities which nobody can understand result.

Imagine if this code[0] wasn't well-documented, fairly clearly written, and also tested. It would definitely be a liability in a codebase.

In addition, the rules of how advanced TypeScript concepts work can be quite nuanced and not always extremely well defined, so you can end up in situations where nobody even _really_ understands why some crazy type works.

[0]: https://github.com/sindresorhus/type-fest/blob/2f418dbbb6182...

[lf-non]

Yes, while that is true, TS errors can sometimes be really clunky. And sans a debugger, it is not uncommon for me to be spending stretches of 20-30 mins almost every week trying to unravel complex type errors that span multiple pages. I recently traced a very weird error to TS changing what keyof never evaluates to in a minor version.

So yeah, using discriminated unions, branded types, mapped types etc. in moderation can substantially reduce the surface area of errors - more so than other mainstream nominally typed languages. However, trying to model and prevent every invalid state at type level can lead to a serious drain in productivity. And, I am not really sure how to draw a line between.

[vore]

I think it depends how far you go: if you start encoding rules into the type system that are undecidable then you can quickly run into trouble.

[tobr]

> You have to wonder whether you could implement TypeScript itself in that language...

I also wonder if you could compile TypeScript to TypeScript types? After all, you want your type manipulation code to be typesafe.

[theogravity]

This is a great list. I feel I'm only scratching the surface when it comes to Typescript, and it would be awesome to have a place where we can see advanced examples of Typescript usage like this.

I've seen many projects where the typing is done so well that it can infer and include all the data I've fed into the TS-defined functions / classes, which is great for IDE autocompletion.

[HyperSane]

What are some of the projects have done typing that well?

[evolveyourmind]

Some other type-only TS projects:

- RegExp matching through types: https://github.com/desi-ivanov/ts-regexp

- Lambda calculus through types: https://github.com/desi-ivanov/ts-lambda-calc

- Brainfuck through types: https://github.com/susisu/typefuck

[joshuakgoldberg]

These are wonderful, thank you!

[pjnz]

I did some fiddling around building a graphql layer with a bunch of complex types. Basically this was trying to encode all the various GraphQL rules into the type system itself e.g. if a resolver takes arguments, ensure that a schema of the correct type is provided as an object etc. I also built a client that would take a schema and ensure you used it correctly at compile time.

Example of the code: https://github.com/pj/typeshaman/blob/main/packages/graphql/...

Documentation is incomplete, unfortunately I had to get a job. I started working on encoding all of SQL as well.

[DonatelloTHM]

These are some of my "Typescript type system" based projects:

Wordle: https://codesandbox.io/s/wordle-typescript-d4srgi?file=/src/...

Anadrome(Anagram Palindrome): https://codesandbox.io/s/anagram-palindrome-7u14xr?file=/src...

Candy Crush 1D: https://codesandbox.io/s/candycrush-u2v5pr?file=/src/index.t...

[adamddev1]

Are there (m)any other languages with type systems as flexible and powerful as Typescript's?

[valenterry]

Yes there are. For instance Idris (https://www.idris-lang.org/) has a way more powerful typesystem than Typescript.

If you are looking for more practical and less academic languages, then Scala would be one of the languages that technically has a more powerful/generalized typesystem but at the same time is harder to use compared to Typescript's and cannot do some things that Typescript can do.

[yulaow]

I believe that typescript type system is so flexible, powerful and complex just because it had to be adapted and built around the shortcomings and limitation of javascript. It makes no sense to have something like it if you build a language from the ground up (or if you could just scrap backward compatibility in a bad designed one)

[cjbgkagh]

I would guess that all languages with Turing complete typesystems would be technically equally powerful. I think Typescript supports more useful behaviors out of the box.

[bichiliad]

If you're going down the rabbit hole of writing complex types, check out Dan Vanderkam's "The Display of Types" post[0]. It goes into how types show up in editors and error messages and such, and has a bunch of tricks for improving type readability. I really wish I read it sooner!

[0]: https://effectivetypescript.com/2022/02/25/gentips-4-display...

[joshuakgoldberg]

TypeScript's type system is Turing Complete: meaning it has conditional branching (conditional types) and works with an arbitrary huge amount of memory. As a result, you can use the type system as its own programming language complete with variables, functions, and recursion. This blog post is a starting list of a bunch of the shenanigans TypeScript developers have pushed the type system to be able to do.

[Gehinnn]

That's not the meaning of turing completeness, just an implication of the space hierarchy theorems. There are systems that also have branching and unbounded memory, but are not turing complete. Context free grammars for example.

Turing completeness means for TS that for every computable function, there is a TS type that can compute that function (if TS wouldn't limit the recursion depth).

[tadfisher]

It also makes static checking undecidable in pathological cases. I know Idris has this problem as well; they work around it by skipping partial functions in types, so you end up with "total" and "partial" programs where only the former are completely typechecked proofs.

[tgv]

Does anybody have a document that describes all type constructions in typescript? The "official" handbook doesn't seem complete. Some time ago, I tried to use tuples in types, but I couldn't figure out the correct syntax. I found some vaguely similar examples on stackoverflow, so it seems some people did get that information.

[graftak]

It helps to read the release notes to keep up to date. https://www.typescriptlang.org/docs/handbook/release-notes/t...

[mbrodersen]

Advanced type systems are fun to play with. But unfortunately some people get carried away and build a mountain of unnecessary complexity that other developers then have to deal with. A bit like Lisp macros. It is fun to implement your own type system and DSLs in Lisp. But the result is likely to be completely unmaintainable by anybody else and yourself a year later when you have forgotten how it works. I have seen the same happen with templates in C++. Developers that spend weeks having fun building a mountain of template hell to solve a problem that could have been solved in a few hours without template magic. As with everything else, keeping an eye on the benefit/cost ratio is key.

[lispm]

I'd expect Lisp macros to be easier to debug, since they are written in Lisp themselves (and not in a template language) and the usual interactive debugging tools apply.

There are lots of Lisp DSLs using macros which have been maintained by different people over several decades.

[truth_seeker]

Very very cool. Thanks for sharing. SQL Database engine source code exceeded my expectation.