Error messages should place most relevant information first.
See original GitHub issueHere’s an actual example of an error message that can go wrong in our library when mispelling a property when creating an object literal:
[ts]
Type '{ containers: { nginx: { image: string; memory: number; portMappings: NetworkListener[]; enviroment: number; }; }; }' is not assignable to type 'FargateTaskDefinitionArgs'.
Types of property 'containers' are incompatible.
Type '{ nginx: { image: string; memory: number; portMappings: NetworkListener[]; enviroment: number; }; }' is not assignable to type 'Record<string, Container>'.
Property 'nginx' is incompatible with index signature.
Type '{ image: string; memory: number; portMappings: NetworkListener[]; enviroment: number; }' is not assignable to type 'Container'.
Object literal may only specify known properties, but 'enviroment' does not exist in
type 'Container'. Did you mean to write 'environment'? [2322]
- fargateService.d.ts(169, 5): The expected type comes from property 'taskDefinitionArgs'
which is declared here on type 'FargateServiceArgs'
The funny thing here is that the final parts of the error message are superb. Namely:
- Object literal may only specify known properties, but 'enviroment' does not exist in
type 'Container'. Did you mean to write 'environment'? [2322]
- fargateService.d.ts(169, 5): The expected type comes from property 'taskDefinitionArgs'
which is declared here on type 'FargateServiceArgs'
However, the actual output is quite cluttered and hard to glean the information from. This is esp. true in an ide setting where one sees something like this:
This view is particularly problematic due to the wrapping and wall-of-goop nature of this type of error.
My suggestion would be to invert the information being provided by errors. Give the most specific and directly impactful information first (i.e. Object literal may only specify known properties, but 'enviroment' does not exist in type 'Container'. Did you mean to write 'environment'?
), and then follow that up with all the extra details that can be used to dive deeper into things when that isn’t clear enough.
Issue Analytics
- State:
- Created 5 years ago
- Reactions:26
- Comments:22 (22 by maintainers)
Top GitHub Comments
Sometimes inside-out is the best error, sometimes outside-in is the best error. It depends on whether your error is because the type “isn’t even close” (i.e. you have the completely wrong kind of object), or if there’s something “subtly wrong” (i.e. you are off by one property spelling or type).
Consider this code:
The error message here is:
The last 7 lines of that error message are not really relevant (it’s not really the error the developer is making, just an explanation of why the assignment is an error), and arguably only the first line is needed for the user to know what’s gone wrong.
Displaying the inner message first here looks like TS has lost its mind:
Hurrdurr. Me smart. Me also on 3.2.2
Where are you now? Our current office is downtown 😄