1. 8
  1.  

    1. 3

      I recently went down a rabbit hole with template literal types: I was trying to enforce correctly shaped string of html at compile time. I got it working, but dropped it due to three reasons:

      1. It’s slow if you use it broadly
      2. The error messages aren’t easy to understand what was wrong
      3. It took effort to implement, and the resulting code was a lot harder to read.

      So I ended up dropping it, and doing some runtime validation instead. It’s a shame, because I think it’s a pretty good use case for compile time checks instead of runtime. Maybe I’ll give it another go after reading some more of the examples linked at the bottom of this post.

      1. 2

        This looks real cool, thanks for sharing.

        One thing that confuses me in the string literal type magic is that we literary have to re-implement the underlying logic in another functional language that is not itself verified. Is it time for TypeScript for TypeScript? Or maybe a new imperative TS to type level TS compiler?

        Jokes aside, I’ve tried recently to verify a type rich code produced by a generator with another generator that would sort of fuzztest the first one while also being validated by the TS compiler. The rules to the unit test generator themselves quickly started looking like a language on their own :D Awesome times!