Flow: Dynamic import errors with computed strings

[doctyper]

The following code triggers a Flow error:

https://flow.org/try/#0PQKgBAAgZgNg9gdzCYAoVBjOA7AzgFzCjjjAF4wBLAWwAc4AnfACgAMA6YWgQ3wAtg+OMAAkAbyx0ArvgCmAEwAKvPgF92AK1ysAlAG5UQA

const foo = import(`./path/to/${computedPath}.js`);
            ^ The parameter passed to import() must be a literal string.

Per the spec:

import() accepts arbitrary strings (with runtime-determined template strings shown here), not just static string literals.

[vkurchatkin]

You need to set module.ignore_non_literal_requires

[doctyper]

Ah, got it. Is there a reason it does throw an error? Is it not spec?

[jeffmo]

We should add that config option to the error message but:

In general this is a limitation of Flow. Flow needs to understand the dependency graph in order to understand the type of a module's imports -- so, by default, Flow asks that you only use literal strings as those are the only statically identifiable option. A fully-typed way to do this kind of import would be to use a switch statement:

let foo;
switch (computedPath) {
  case "path1"
    foo = import("./path/to/path1.js");
    break;
  case "path2":
    foo = import("./path/to/path2.js");
    break;
  ...
}

If you use the config option, Flow will suppress the warning and type dynamic imports that it can't resolve as any
}

[nickshanks]

This error message is just a straight-up lie. It makes it look like import (x) does not allow non-string-literal arguments (plausible, since it is a language construct not a function, and so might have unusual requirements).
In reality, there's nothing wrong with specifying an expression, other than Flow throwing a hissy fit, and sending developers on an expedition across the internet trying to find why it isn't allowed.