Autoimport: Prefer Secondary Entrypoint

Suggestion

🔍 Search Terms

• secondary auto import

✅ 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

When auto importing it would be nice if the importer prefered secondary entry points instead of main entry point, as it gets tiresome having to modify or manually write the imports to use a secondary entry point.

Note: It does use the secondary entrypoint if it has already been defined in the file. However, this is for on initial import.

📃 Motivating Example

This allows compilers (such as webpack) to tree-shaking. If including the main entry point all modules get included in the build (for libraries that have them all exported in the main entry point) whereas importing secondary entry points only includes (usually) parts of the library.

💻 Use Cases

Workaround: Manually updating every import every time.

No files, tests, or entry points are named. Start by locating TypeScript's auto-import implementation and compare initial import selection with the existing behavior when a secondary entry point is already present. Done means initial auto-imports prefer appropriate secondary entry points without changing runtime behavior.