Option for auto-import to prefer direct exports over re-exports

Suggestion

🔍 Search Terms

vscode, autoimport, importModuleSpecifier, "re-export", barrel, tree-shaking

✅ 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

Some libraries provide the ability to import modules using sub-path module specifiers (import {SubModule} from "@scope/library/submodule", as well as re-exporting the module at top level (import {SubModule} from "@scope/library"). In some circumstances, it is desirable to prefer the sub-path specifier over the top level ("barrel") re-export. I don't see any way to do that using the current importModuleSpecifier options.

Ideally, the mode would resolve the preferred specifier, then walk up any export from statements and use the original source. If that's not possible, perhaps an MRU option could be implemented, so that if I manually pick a specifier path for a given module once, that same path is used for future auto-imports.

💻 Use Cases

I normally stick to the default "shortest" preference, which prefers the top-level re-export (if present). This makes the build tooling work harder to prove that a given module is tree-shakable, and in rare cases can lead to circular reference issues, as the load order of interdependent barrel exports becomes too convoluted to untangle automatically. Importing only the sub-module being used can avoid these problems.

Start by tracing TypeScript's auto-import handling for the importModuleSpecifier option and the existing shortest preference. Compare the requested direct-export preference with the current re-export behavior, then identify how it should be exposed and tested. Done means users can select a preference that favors sub-path specifiers without changing existing defaults.