Narrowing string down to a module specifier

[valler]

🔍 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.

[RyanCavanaugh]

This is pretty fraught. Right away a few huge problems come to mind

• Resolving one specifier can cause another specifier to become valid, e.g. you import a file "bar" which in turns pulls in a declare module "foo" {.
• How exactly do relative paths work here? The same literal could resolve in one place but not another. Which file is the resolution done relative to?

[mkantor]

I think this may be a duplicate of #32401 (or at least a close relative of it). But I also don't think I understand the Resolvable part of this proposal (why wouldn't you want this to work?).

[valler]

@RyanCavanaugh

I'm not sure if I understand the first bullet correctly. The way I had it in mind only strings of type Resolvable would be relevant and they don't import anything (at runtime), all they do is static resolution so devs could get information without having to write an import (yet).

About the second bullet: It should resolve as if one had written import(x) instead of x wherever one needs intellisense, otherwise I could not imagine how it would be JS compatible without runtime code transformation. In every other way it's just a string value. I understand your concerns. E.g. one could mistakenly expect static, lexically scoped semantics. Especially the reassignment restrictions part (assignability narrower than string) becomes tricky or impossible with that, now I see.

Altogether the Resolvable was the first thing that came to mind to make things palpable. The general idea is "resolve this string for me right here, right now". It should not be a replacement or workaround for tags or discriminators in wrapper objects or wrapper functions. It's literally the other way around, those patterns are kind of more complicated ways to "move around" module specifiers at runtime before the actual call happens. Just having the string reference would be quite a bit simpler and more elegant than any wrapper. In JS one would simply use a string and it would be nice if TS was able to keep it that way but with added type safety and intellisense. If more type safety is not achievable, then the intellisense part alone is maybe more an IDE issue, not one for the language.

@mkantor what I meant is, now you get intellisense for (right at) import(specifier), but I was thinking that it would be quite handy to be able to get it (earlier) where the string literal is defined.