Elaborate on non-portable types

Suggestion

🔍 Search Terms

type annotation elaboration not portable cannot be named

✅ Viability 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, new syntax sugar for JS, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

⭐ Suggestion

To improve DX this error message should mention what part of the type is not portable:

The inferred type of 'XX' cannot be named without a reference to '../../lib/foo'. This is likely not portable. A type annotation is necessary.

Perhaps it could even suggest what export is missing in the referenced module.

I've experienced a situation in which an inferred return value was an object with multiple properties and some nesting. One of its properties had a non-portable type. It would be a huge improvement if the error message could mention which property is not portable (let's say user in this example) and it would be even a bigger improvement if the name of the said type would be mentioned (let's say User in this example)

No files, tests, or entry points are named. Start by locating the diagnostic for inferred types that cannot be named without a reference, then trace how the non-portable part is identified; done means the error identifies the affected property and type where possible.