Allow constant strings as string literals for dynamic import statements.

Search Terms

Use constant string in place of string literal for dynamic import statements.

Suggestion

Honestly I don’t know if this is a bug or a suggestion.

Is there a way to allow constant string to represent string literals? I’m thinking this should work, but it doesn’t. For example:

const moduleName = "../../../Project/src/Mod";

async function doSomething() {
    var mod = await import(moduleName); // (works only if a string literal at the moment)
}

In the case above, “mod” is of type “any” because the compiler doesn’t recognize the string literal in the constant moduleName (for literal strings, the types are correctly pulled). I’m not sure if this was an oversight, but it makes sense to allow it, since constant strings cannot be reassigned. The only workaround is to wrap await import("../../../Project/src/Mod"); in a function:

async function getMod() { return import("../../../Project/src/Mod"); }
async function doSomething() {
    var mod = await getMod(); // (method required since const strings cannot be used to import module type)
}    

I may also add, it seems very difficult to import namespaces using dynamic imports, which I think is another terrible oversight.

async function doSomething() {
    var mod = await import("../../../Project/src/Mod"); // (forced to use a string literal to get typings)
    var o: mod.SomeClass; // ERROR, cannot find namespace 'mod'
    // var o: InstanceType<typeof mod.SomeClass>; // workaround1
    // var o: import("../../../Project/src/Mod").SomeClass; // workaround2 (who wants to keep typing full paths? A const string would be nice here.)
}

That doesn’t even make sense. A namespace, while a type, is still a reference under the hood, and thus should still be importable dynamically somehow; perhaps like:

async function doSomething() {
    import mod = await import("../../../Project/src/Mod"); // (forced to use a string literal to get typings)
    var o: mod.SomeClass;
}

I think all this would aim to better support dynamic imports “on demand” instead of modules forcibly loading every single module when some may not be needed at all, It could also help promote faster initial page loads in many cases. 😉

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, etc.)
• This feature would agree with the rest of TypeScript’s Design Goals.

[rbuckton]

Wouldn’t this possibly involve needing to parse and rebind during check if the imported file wasn’t previously part of the compilation? I could only see this work for files already included in the program.

[ShanonJackson]

Just to throw my use case in as well as i’d actually really like generics in import types. I.E type importOf<T extends string> = typeof import(T); This will allow incredible new possibilities for my isomorphic projects because i’ll be able to do this…

const fetchUsers = api("./api/get-name")

const api<T extends string>(url: string): Promise<ReturnType<typeof import(T)["default"]>> => {
      return fetch(url.replace(".", "")
}

Where all my API endpoints export a default endpoint and which returns some data. If anyone uses NextJS with typescript they’ll know this would be an insanely useful feature because NextJS enforces file-path routing therefore all endpoints export a default and are from the same file as the url path.