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

[thw0rted]

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.

[thw0rted]

After writing this, I saw #41083 which isn't quite the same thing, but might also be solved by adding MRU tracking. I wouldn't mind not having a do-what-I-mean importModuleSpecifier if I could just "train" the auto-imports by choosing the right one manually a couple of times.

[ShaMan123]

+1
I am a maintainer developing a library. We have index files exposed for bundling but I don't want auto import to default to them while I develop the project since it causes import cycles.
Having a setting directImports: true would be great

This is what I found in setting, unrelated

[wkronemeijer]

I have the same problem. For my library, all exports are rolled into a barrel module (called "Modules.generated.ts"), which re-exports every other module. Now, when I try to import a neighbour, it tries to auto-import the top-level barrel module, which causes circular module importing.

There are multiple aspects to this:

• Outside of the project (rootDir), I want auto-import to prioritize the re-export.
• Inside of the project, I want auto-import to prioritize the original, not the re-exported value.

I would personally want to trigger this behavior for a specific module with a directive comment, like // @ts-external-export. But a setting would also work. I don't think that everyone wants this behavior ON at all times.

[benwick]

It seems logical to have this. Barrel modules are only for external use. But when you are working on your package, you want the direct imports.