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.

ファイル、テスト、エントリポイントは指定されていません。まず TypeScript の auto-import 実装を見つけ、セカンダリエントリポイントがすでに存在する場合の既存の動作と、初期の import 選択を比較してください。初期の auto-import が適切なセカンダリエントリポイントを優先し、ランタイムの動作を変更しなければ完了です。