Skip to content

TsConfig: flatten type errors. "Advanced Type" errors currently often unreadable. #35246

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
5 tasks done
SephReed opened this issue Nov 20, 2019 · 2 comments
Closed
5 tasks done
Labels
Awaiting More Feedback This means we'd like to hear from more people who would be helped by this feature Suggestion An idea for TypeScript

Comments

@SephReed
Copy link

SephReed commented Nov 20, 2019

Search Terms

"Type error read"
"type errors unreadable"

Suggestion

Type checking, and type definitions errors could me made significantly easier to debug by flattening/boiling down the type definitions to something more resembling what developers think of them as.

  1. This first example shows the kind of errors I run into in actual development. It's totally unreadable.

Screen Shot 2019-11-20 at 3 58 27 PM

  1. This second example shows the same effect

Screen Shot 2019-11-20 at 4 02 52 PM

Screen Shot 2019-11-20 at 4 01 34 PM

For this second example, it would be a lot more useful if instead it just showed what the type realistically is, and what it was missing. Ie:

Property "badProp" does not exist on type '{
  requestId: string;
  type: string;
  id?: string;
  createdAt?: Date;
  data?: string;
}'

This would be a really nice thing to add to tsconfig.

Use Cases

Almost 100% of the time one works with advanced types. Anything involving unions or (worst of all) utility types creates a wall of text.

Examples

// ts.config
{
  flattenTypesInMessaging: true
}

(I'll make a habit of posting all my most unreadable messages here)

Checklist

My suggestion meets these guidelines:

  • This wouldn't be a breaking change in existing TypeScript/JavaScript code
  • This wouldn't change the runtime behavior of existing JavaScript code
  • This could be implemented without emitting different JS based on the types of the expressions
  • This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
  • This feature would agree with the rest of TypeScript's Design Goals.
@SephReed SephReed changed the title TsConfig: flatten type errors. Type errors currently unreadable. TsConfig: flatten type errors. Type errors currently often unreadable. Nov 20, 2019
@SephReed SephReed changed the title TsConfig: flatten type errors. Type errors currently often unreadable. TsConfig: flatten type errors. "Advanced Type" errors currently often unreadable. Nov 20, 2019
@RyanCavanaugh
Copy link
Member

I really meant it in #35247 when I said we wanted a way to reproduce that error 😢

@RyanCavanaugh RyanCavanaugh added Awaiting More Feedback This means we'd like to hear from more people who would be helped by this feature Suggestion An idea for TypeScript labels Nov 22, 2019
@SephReed
Copy link
Author

I had made these at the same time, unsure of whether or not it was a vscode or typescript issue. The other one you linked was posted in vscode and moved here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Awaiting More Feedback This means we'd like to hear from more people who would be helped by this feature Suggestion An idea for TypeScript
Projects
None yet
Development

No branches or pull requests

2 participants