Suggestion

Expand the (very nice) ability to infer the type of an import() call expression so that such imports can be wrapped.

🔍 Search Terms

typeof 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

Make it possible to expose the type of what a module exports:

function loadModule<T extends string>(modulePath: T): Promise<typeof import(T)>;

📃 Motivating Example

Library code that allows plugins, lazy-loading, etc. needs the user code to perform the import call itself in order to get typing information.

const plugin = await loadPlugin('@project/x/y', 'exportedFunction');

Without the feature, anything can be used instead of exportedFunction, but with the feature it would be possible to restrict the name and type the result:

function loadPlugin<
  ModuleName extends string,
  ExportName extends keyof typeof import(ModuleName)
>(
  moduleName: ModuleName,
  exportName: ExportName
): Promise<Plugin<typeof import(ModuleName)[ExportName]>>;

That's a fairly simple example, but it becomes more interesting when passing functions that would receive those exported objects as their parameters, etc.

💻 Use Cases

Usage:

• plugin mechanisms
• lazy-loading features
• build-time DSLs

Short-comings with the current approach:

• nothing but import() can be used while keeping type information

Short-comings with the proposed approach:

• tooling may sometimes need to be adapted to "detect" such new import constructs

Workarounds:

• not many are available apart from importing the type/re-declaring separately