You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Consider collapsing multiple repeated type-related error messages when in --pretty #23393
The TS team started a few conversations in TSConf 2018 about making TypeScript error messages more friendly to newcomers. One good first one to approach could be repeated, near-identical errors around the same type.
Code
For example, if a type is missing multiple times in the same file:
leta: MissingType;letb: MissingType;// ..letc: MissingType;
Expected behavior:
In a debatably perfect world, TypeScript could give a single error message for the repeated class of error:
src/index.ts Error TS2304: Cannot find name 'MissingType'.
1 let a: MissingType;
~~~~~~~~~~~
2 let b: MissingType;
~~~~~~~~~~~
4 let c: MissingType;
~~~~~~~~~~~
Actual behavior:
Three separate errors.
Perhaps a post-processing step in --pretty mode that receives all of a file's errors and smooshes them down when it can?
Some open questions:
Which classes of errors would be in this bucket?
Example: TS2304 missing type if the type is the same
Example: TS2339 property does not exist if the type and property are the same
How should this look?
As suggested above, which is similar to existing --pretty output but with line+column removed?
If there are a many of the same error, should the output truncate with a summary?
#10489 and #22789 both discuss the idea of related spans which could be leveraged here, but you really want to cut down on these. We could defer all "cannot find" error messages to the end of the checking process and potentially de-dupe in that fashion.
The problem is that you really want to still present the related spans outside of pretty, so we'd need to report a different error depending on pretty which feels bad-ish.
We have had a discussion about this offline. An observation here is that usually the duplicate declaration errors are caused by including the same module/declaration file more than once. so the result is multiple duplicate declaration errors for the same 2 files. A proposal for improvement here is if we notice a single file has more than X (say 5) duplicate declaration errors with the same file, then only report the first one with an elaboration saying that there are multiple errors there. #25324 track this suggestion.
Activity
DanielRosenwasser commentedon Apr 13, 2018
DanielRosenwasser commentedon Apr 13, 2018
#10489 and #22789 both discuss the idea of related spans which could be leveraged here, but you really want to cut down on these. We could defer all "cannot find" error messages to the end of the checking process and potentially de-dupe in that fashion.
The problem is that you really want to still present the related spans outside of
pretty, so we'd need to report a different error depending onprettywhich feels bad-ish.RyanCavanaugh commentedon Apr 17, 2018
Revisit once we have general multi-location diagnostic support.
Some notes in #23444
DanielRosenwasser commentedon Jun 26, 2018
I think this should also cover
Cannot redeclare block-scoped variable '{0}'mhegazy commentedon Jun 29, 2018
We have had a discussion about this offline. An observation here is that usually the duplicate declaration errors are caused by including the same module/declaration file more than once. so the result is multiple duplicate declaration errors for the same 2 files. A proposal for improvement here is if we notice a single file has more than X (say 5) duplicate declaration errors with the same file, then only report the first one with an elaboration saying that there are multiple errors there. #25324 track this suggestion.
DanielRosenwasser commentedon Jun 30, 2018
Also, related to this is #15550
mhegazy commentedon Jul 2, 2018
with #25324, I think we can call the underlying issue addressed.