Skip to content

Consider collapsing multiple repeated type-related error messages when in --pretty #23393

Closed

Description

Search Terms: error message pretty collapsing

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:

let a: MissingType;
let b: MissingType;
// ..
let c: 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?

Activity

  1. DanielRosenwasser commented on Apr 13, 2018

    @DanielRosenwasser
    Member
    and smooshes them down when it can?

    and smooshes them down when it can?

    and smooshes them down when it can?

    and smooshes them down

    and smooshes

    image

  2. DanielRosenwasser commented on Apr 13, 2018

    @DanielRosenwasser
    Member

    #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.

  3. RyanCavanaugh commented on Apr 17, 2018

    @RyanCavanaugh
    Member

    Revisit once we have general multi-location diagnostic support.

    Some notes in #23444

  4. DanielRosenwasser commented on Jun 26, 2018

    @DanielRosenwasser
    Member

    I think this should also cover Cannot redeclare block-scoped variable '{0}'

  5. mhegazy commented on Jun 29, 2018

    @mhegazy
    Contributor

    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.

  6. DanielRosenwasser commented on Jun 30, 2018

    @DanielRosenwasser
    Member

    Also, related to this is #15550

  7. mhegazy commented on Jul 2, 2018

    @mhegazy
    Contributor

    with #25324, I think we can call the underlying issue addressed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Domain: Error MessagesThe issue relates to error messagingDomain: Related Error SpansSpecifying regions for error messages/diagnostics on multiple locations.FixedA PR has been merged for this issueSuggestionAn idea for TypeScript

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions