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)