-
Notifications
You must be signed in to change notification settings - Fork 12.4k
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
Use the width of a type to add newlines in type assignment error messages #45896
Comments
Hey @orta, I am a typescript beginner and want to contribute here, could you guide me where to start? |
Sure, first read the READMEs/contributing guides - I think all of the changes will probably live inside
|
Then it becomes a garden path sentence:
"What's a type string? Does that mean literal string types? Oh wait, it means the actual type 'string'." It's better with the quotes. |
Hello ! @heyAyushh Please let me know if you are not working on this anymore so that I can take this forward 😊 |
@prabhatmishra33 I think @cytler is already working on it, |
Hi @DanielRosenwasser, I'm just looking at how I might implement a change for this issue and noticed your comment on the PR that was previously opened for this issue. I wanted to clarify your thoughts on one point that you made.
I agree that this seems like a sensible option, however, with the way that the diagnostic message generation works (at least from my current understanding) to introduce a second "pretty" message it would need to be created with a new error code as the generation script will error out if it finds duplicate codes. Would you be comfortable with introducing a new error code for the "pretty" messages? Personally, that doesn't feel like something that should be done for the sake of introducing some nicer formatting, but I'd be interested to hear your thoughts on this as I might be missing some context/domain knowledge that makes the answer clearer. |
Sorry for the delay - yup, adding a new error code is fine. |
Hey guys, first time contributor here! Was wondering if I could tackle this issue? It seems stagnant and I am eager to help! |
While this issue is still open, I’d like to point out that the keys in structured types are also unsorted. For instance, I receive the error (formatting by me)
It would help if the keys were in the same order. |
is this issue still open? |
Today we ship a one-type-fits-all style for printing type is not assignable to type messages. We'd like to improve this in a pretty simple manner: by occasionally adding newlines. For example with this arbitrary comparison:
Looks like this today:
I propose that because both of the printed types are longer than 20-30 chars, then we switch to:
Key details
Some Examples
No changes
src/index.ts(21,1): error TS2322: Type 'string' is not assignable to type 'number'.
src/index.ts(21,1): error TS2322: Type 'string' is not assignable to type 'number'.
No change! (Though a part of me does really want to drop the quotes for primitives)
No change!
{}
andWindow & typeof globalThis
are too small.Changing one
Changing both
The text was updated successfully, but these errors were encountered: