Open orta opened 3 years ago
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 reportRelationError(message: DiagnosticMessage | undefined, source: Type, target: Type
in checker.ts
- somewhere around lines 17790.
sourceType
and targetType
are the strings, you need to use the length of to determine what to do
Though a part of me does really want to drop the quotes for primitives
Then it becomes a garden path sentence:
Type string is not assignable to type number
"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.
Yeah, exactly, I don't disagree - just pining for a better way to visually distinguish between type and message e.g.
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 think the right fix here is actually to create new diagnostics for specific well-known ones and swap them out; especially since a diagnostic might mention the same type multiple times.
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)
Type
{
tariffId: FormControl<TariffId>;
tariffChoiceIds: FormControl<TariffChoiceId[]>;
startDate: FormControl<ISODate>;
endDate: FormControl<ISODate | null>;
// lots more
}
is not assignable to type
{
startDate: FormControl<ISODate>;
endDate: FormControl<ISODate | null>;
overlappingPeriod: FormControl<null>;
tariffId: FormControl<TariffId>;
// Lots more
}
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