The second I saw this, I thought: maybe this will be the kick the TS team has needed to try to make their error messages more like Rust’s and Elm’s. I’ve been helping a bunch of folks on my team learn TS lately as we are migrating all of LinkedIn’s internal JS infrastructure code and foundational parts of the flagship app to TypeScript and… the complaints about and confusion about the error messages have not been few!
the complaints about and confusion about the error messages have not been few
When writing some “gnarly” types in TypeScript I’ve generally relied more on my intuition and knowledge of how “types work” rather than the error messages from tsc. But no one on my team uses the “advanced” features of TypeScript’s type system, so they generally don’t encounter bad error messages.
Yeah, we’re an infra team working on converting a bunch of infra code… and infrastructure libraries tend to be the nastiest code for this kind of thing, for two reasons (likely apparent to you, perhaps less so to others reading):
It’s library code, and library code which tries to present a nice interface to end users often has to jump through some hoops to make that happen. This TypeScript Congress talk (not publicly available yet; it was an online conference) by Mark Erikson (Redux maintainer) covers a bunch of why that tends to be. The short version is: more generics, more unions, more other fancy type shenanigans.
It deals with backwards compatibility much more than app code does, which means it has to jump through many more hoops, which again leads to use of overloads, generics, conditional types, etc.
App code can usually be more or less “write types for function inputs and outputs and object types and everything else just works”, so I am fairly confident folks working in the app itself will hit a lot less of this.
It’s library code, and library code which tries to present a nice interface to end users often has to jump through some hoops to make that happen.
This is definitely where I’ve seen the most complexity with TS. It’d be a big win if the errors could be improved, because oftentimes the alternative of looking at library type definitions can be overwhelming (at least for me, a novice Typescripter). I always think “there’s a learning opportunity here” but then I also just want to fix my error and move on, so it can be hard to balance.
Conversion of type 'string' to type 'string[]' may be a mistake because neither type sufficiently overlaps with the other. If this was intentional, convert the expression to 'unknown' first.
is translated to
You can’t use ‘as’ to convert string into a string[] - they don’t share enough in common.
You’re correct that it has translated it that way (and accurately). If you’re used to doing the work of translating type errors into what they mean in your head from working in other typed languages, it may not be more clear… but it is, in my experience, much clearer and easier for someone reading along who is learning the language. Also: brevity is not always better for clarity (some opinionated manuals of style notwithstanding), and tone can go a long way to making the language feel more approachable to folks who are new to types—which is many, perhaps most TypeScript developers when they first start, given they’re coming from JavaScript.
Just to clarify I was not criticizing the goal of the project. I was only suggesting that perhaps another example would be more enticing given that’s the first thing a prospective user will see.
The only thing I’ve learned to help me understand the giant and impenetrable TS errors is to read the last part first. Often there’s a straightforward clue there. I’d love to see the errors improved.
The second I saw this, I thought: maybe this will be the kick the TS team has needed to try to make their error messages more like Rust’s and Elm’s. I’ve been helping a bunch of folks on my team learn TS lately as we are migrating all of LinkedIn’s internal JS infrastructure code and foundational parts of the flagship app to TypeScript and… the complaints about and confusion about the error messages have not been few!
When writing some “gnarly” types in TypeScript I’ve generally relied more on my intuition and knowledge of how “types work” rather than the error messages from
tsc. But no one on my team uses the “advanced” features of TypeScript’s type system, so they generally don’t encounter bad error messages.Yeah, we’re an infra team working on converting a bunch of infra code… and infrastructure libraries tend to be the nastiest code for this kind of thing, for two reasons (likely apparent to you, perhaps less so to others reading):
It’s library code, and library code which tries to present a nice interface to end users often has to jump through some hoops to make that happen. This TypeScript Congress talk (not publicly available yet; it was an online conference) by Mark Erikson (Redux maintainer) covers a bunch of why that tends to be. The short version is: more generics, more unions, more other fancy type shenanigans.
It deals with backwards compatibility much more than app code does, which means it has to jump through many more hoops, which again leads to use of overloads, generics, conditional types, etc.
App code can usually be more or less “write types for function inputs and outputs and object types and everything else just works”, so I am fairly confident folks working in the app itself will hit a lot less of this.
This is definitely where I’ve seen the most complexity with TS. It’d be a big win if the errors could be improved, because oftentimes the alternative of looking at library type definitions can be overwhelming (at least for me, a novice Typescripter). I always think “there’s a learning opportunity here” but then I also just want to fix my error and move on, so it can be hard to balance.
Awesome! Can they do one for C++ next?
I’ve never used TypeScript but am I correct in assuming that this package has translated:
to:
?
The TL;DR isn’t shorter, nor more clear. Probably a bad example for a prominent show case.
There’s a better (in my opinion) example on the demo website:
is translated to
You’re correct that it has translated it that way (and accurately). If you’re used to doing the work of translating type errors into what they mean in your head from working in other typed languages, it may not be more clear… but it is, in my experience, much clearer and easier for someone reading along who is learning the language. Also: brevity is not always better for clarity (some opinionated manuals of style notwithstanding), and tone can go a long way to making the language feel more approachable to folks who are new to types—which is many, perhaps most TypeScript developers when they first start, given they’re coming from JavaScript.
Just to clarify I was not criticizing the goal of the project. I was only suggesting that perhaps another example would be more enticing given that’s the first thing a prospective user will see.
Ah, I see – I agree that @cherryblossom’s sibling comment would indeed be a better motivating example!
The only thing I’ve learned to help me understand the giant and impenetrable TS errors is to read the last part first. Often there’s a straightforward clue there. I’d love to see the errors improved.