Synchronous dynamic imports

[hydroperx]

🔍 Search Terms

synchronous dynamic import

✅ Viability Checklist

• 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 isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
• This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

⭐ Suggestion

An import.sync("path/to/module") expression that dynamically, synchronously imports a module as if it were rewritten to:

import * as _i_f9aef from "path/to/module";

// where the expression appeared...
_i_f9aef

I have also considered import synchronized but it is more verbose and does not look like an expression.

📃 Motivating Example

Importing modules synchronously is useful in few contexts:

Static: projects that import multiple static media such as images, which, for certain reasons cannot use import() directly as other code regions may read their value directly statically (say IconRegistry.get(iconId)), would duplicate the effort for integrating these images when using the top-level import statement.

Name conflict: if lexical names are ambiguous, top-level import statements always have to be tweaked for aliases.

Importing modules synchronously inline allows overcoming these situations:

// integrating static icons
IconRegistry.set("arrow", {
    black: import.sync("../icons/arrow-black.svg").default,
    white: import.sync("../icons/arrow-white.svg").default,
});

// solving name conflict
new import.sync("max").Vector(x, y)
new import.sync("org.generalrelativity.foam").Vector(x, y)

💻 Use Cases

1. What do you want to use this for? A new HTML5/Node.js ecosystem.
2. What shortcomings exist with current approaches? They are verbose. I have a library that has to import multiple icons and basically having to use import statements means double work for contributing new icons.
3. What workarounds are you using in the meantime? Using separate import statements, doubling work.