Disambiguate union errors when type name is the same, but namespace differs

[shabbyrobe]

Search Terms

• namespaces error
• same type error
• ambiguous type name error
• namespace type name error
• union type same name
• "does not satisfy the constraint" duplicate
• "does not satisfy the constraint" error
• "is not assignable to type" duplicate
• "is not assignable to type" duplicate error
• "is not assignable to type" namespace error

Found nothing, but my issue title turned this up: #1419, which appears to be not-entirely-unrelated, but has been marked as "fixed".

Suggestion

When multiple variants of the same union have the same type name, but are in different namespaces, assignability errors repeat the type name without qualification. The following code reproduces the issue:

namespace Foo {
  export type Yep = { type: "foo.yep" };
}

namespace Bar {
  export type Yep = { type: "bar.yep" };
}

const x = { type: "wat.nup" };
const val: Foo.Yep | Bar.Yep = x;

The following error is produced using 3.6.3:

error TS2322: Type '{ type: string; }' is not assignable to type 'Yep | Yep'.
  Type '{ type: string; }' is not assignable to type 'Yep'.
    Types of property 'type' are incompatible.
      Type 'string' is not assignable to type '"bar.yep"'.

I think it would help a lot if the error message was able to include as many parent namespace segments as necessary to present the type names unambiguously:

error TS2322: Type '{ type: string; }' is not assignable to type 'Foo.Yep | Bar.Yep'.

Use Cases

We use namespaces extensively in our codebase, often in unions with many more variants than the above example. It's impossible to debug typing issues when we are confronted with error messages like this:

Type '...' is not assignable to type 'Entity | Entity | Entity | Entity | Entity | Entity | undefined'

Checklist

My suggestion meets these guidelines:

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.