TypeScript 3.0 related error spans meta issue · Issue #25257 · microsoft/TypeScript (original) (raw)

For TypeScript 3.0, we plan to support error messages with multiple spans (#10489, #22789, #24548). This means we can provide additional context on a given error.

Editor experience

You can give the latest VS Code Insiders a try to see how this currently feels.

@mjbvz may be interested in feedback here.

New Messages

In #22789 (comment), we reviewed the set of error messages that were candidates for multi-span errors; however, we feel that there are a set of errors that would provide the most impact if we prioritized them (i.e. they'd give users the most bang for the buck):

• Calling CommonJS modules imported with import * (Introduce related spans into tsserver protocol #24548)
• Errors spans for assignability of object properties (Related error spans for assignability checks #25030)
• Referencing the "Did you mean..." declaration (Related error span for "did you mean ...?" error messages #25031)
• Variable used before declaration (Add related error spans for use-before-declaration #25003)
• Spans on duplicate declarations across files (Limit duplicate declaration errors #25324)

These messages didn't make in in time for 3.0, but we are still interested in them! Keep tabs on them over at #26077.

• Errors on base members with derived classes (Related error spans for derived members in interfaces/classes #25033)
• Too few arguments (Related error spans for too few arguments #25255)
• Mismatched getters/setters (Add related error spans for getter/setters with different types #25002 🏃)
• Errors on multiple default exports (Related error spans for multiple default exports #25032 🏃)

(:running_man: implies we have an existing PR)

We also have some other diagnostics that we'd love to get to, but have a finite set of resources. If anyone from the community is interested in prioritizing these messages, please feel free to grab an item from the below list, create an issue, and send us a pull request!

• Types have separate declarations of a private property '{0}'.
• Property '{0}' is protected but type '{1}' is not a class derived from '{2}'.
• Property '{0}' is protected in type '{1}' but public in type '{2}'.
• JSX attributes listed twice: '{0}' are specified twice. The attribute named '{0}' will be overwritten.
• Inconsistent type parameter names: All declarations of '{0}' must have identical type parameters.
• Type '{0}' is not assignable to type '{1}'. Two different types with this name exist, but they are unrelated.
• _____ has or is using private name '{1}'
• Subsequent property declarations must have the same type. Property '{0}' must be of type '{1}', but here has type '{2}'.
• Accessors must both be abstract or non-abstract.
• Overload signatures must all be ______
• Overload signature is not compatible with function implementation.
• Individual declarations in merged declaration '{0}' must be all exported or all local.
• Subsequent variable declarations must have the same type. Variable '{0}' must be of type '{1}', but here has type '{2}'.
• In an enum with multiple declarations, only one declaration can omit an initializer for its first enum element.
• Namespace merging
  • A namespace declaration cannot be in a different file from a class or function with which it is merged.
  • A namespace declaration cannot be located prior to a class or function with which it is merged.
• Module '{0}' is hidden by a local declaration with the same name.
  • should probably be changed to "namespace"
• An AMD module cannot have multiple name assignments.
• Cannot initialize outer scoped variable '{0}' in the same scope as block scoped declaration '{1}'
• Export declaration conflicts with exported declaration of '{0}'.
• Cannot redeclare identifier '{0}' in catch clause.
• Module '{0}' uses 'export =' and cannot be used with 'export *'.
• Base constructors must all have the same return type.
• Overload signatures must all be abstract or non-abstract.
• Type '{0}' has no properties in common with type '{1}'.
• Base class expressions cannot reference class type parameters.
• A member initializer in a enum declaration cannot reference members declared after it, including members defined in other enums.
• '{0}' refers to a UMD global, but the current file is a module. Consider adding an import instead.
• All declarations of '{0}' must have identical modifiers.
• A computed property name cannot reference a type parameter from its containing type.
• Type argument candidate '{1}' is not a valid type argument because it is not a supertype of candidate '{0}'.