Narrowing string down to a module specifier

🔍 Search Terms

string, narrow, module, import, specifier

✅ 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

Being able to declare a string as resolvable (a module specifier), without having to use an actual import or typeof import(specifier).

📃 Motivating Example

The following shows what this issue is about, using a hypothetical Resolvable:

// Would be nice if one could resolve/dereference these anywhere, not only inside `import`.
// Get intellisense and type checker support for string and identifier here:
const foo: Resolvable = "foo";
const bar: Resolvable = "bar";

// and here:
const b: Record<string, Resolvable> = {
  [foo],
  baz: bar,
};

// Nuh-uh: "Hello World!" is not resolvable;
b[foo] = "Hello World!";

// and anywhere;
await import(feelingBazyToday ? b["baz"] : b[foo]);

The following shows a workaround, with clearly different DX and architecture.

const foo = "foo";
const bar = "bar";

// Is the following pattern beneficial or does it hurt?
// To me it looks like useless wrappers and repetition.
// It's also harder to describe the `typeof a`, although
// one may rely on inference in some situations.
const a: Record<string, ((...x: any[]) => GoodLuck)> = {
  foo: () => import(foo),
  baz: () => import(bar),
};

// May or may not be ok, but it's a different problem.
a[foo] = console.log;

await (feelingBazyToday ? a["baz"] : a[foo])();

💻 Use Cases

1. What do you want to use this for?
2. What shortcomings exist with current approaches?
3. What workarounds are you using in the meantime?

1. Improving DX in IDEs without compromising on runtime code. In particular it would help prevent errors everywhere a (future) module specifier string is decoupled from the dynamic import.

2. Dynamic imports have runtime effects. It's currently not possible to dereference a specifier before use (anywhere it might appear).

3. Either: Writing typeof import(foo) (and deleting it again), when one wants to know (or navigate to) what foo would resolve to. This partially solves the problem, by effectively validating the string, but that information is lost. Or: A different architecture similar to the workaround in the motivating example. Also note, that the described feature can't be implemented in TS user land with things like utility types or type discrimination; so it's not merely sugar for existing functionality. Every workaround will lack a key aspect of the described feature.

No source file, test, or entry point is named. Start by reviewing the suggestion and motivating examples, then determine how a resolvable module-specifier type would support checking and navigation without changing emitted JavaScript; done would include a decided design and corresponding type-checker and IDE behavior.