Deno: Resolve dynamic imports of bare module specifiers at runtime

[caspervonb]

Seems that bare module specifiers aren't resolved at runtime.

Example

try {
  await import("bare_module_specifier");
} catch (err) {
  console.log(err);
}

Results in the following compile time error

error: TS2307 [ERROR]: Cannot find module 'bare_module_specifier' or its corresponding type declarations.
 await import("bare_module_specifier");

This should be resolved at runtime, that's kind of the point of dynamic imports with top level await.

[kitsonk]

That isn't a runtime error, that is a TypeScript error. You can't catch TypeScript errors.

[caspervonb]

That isn't a runtime error, that is a TypeScript error. You can't catch TypeScript errors.

I know, like I said: "Seems that bare module specifiers aren't resolved at runtime." I'm saying that this should probably be a runtime check, at-least in the case dynamic imports.

[jacobgc]

@caspervonb That's not the case, you aren't even getting to the runtime. Typescript cant compile your code...

[caspervonb]

That's not the case, you aren't even getting to the runtime. Typescript cant compile your code...

I know, again, I'm saying we should change this into a runtime check.

[kitsonk]

I see. The title is confusing, along with the code example.

I suspect we should just swallow compile time dynamic import errors.

[bartlomieju]

@kitsonk @caspervonb isn't it one of TS features that it analyses statically resolvable dynamic imports? I think following example would also work:

try {
  const s = "bare_module_specifier";
  await import(s);
} catch (err) {
  console.log(err);
}

If I'm not mistaken we use that feature in bundling (ref https://github.com/denoland/deno/issues/6156)

[kitsonk]

Yeah, after I commented I had that in the back of my mind. How would this suddenly ever become resolvable at runtime? It would always be an error, unless there is an import map, but then why wouldn't you use the import map at design time?

[phil294]

Dynamic imports in general dont work in Javascript-only Deno, unless you use the variable workaround mentioned above or specify --no-check, which probably isnt very intuitive when running a plain JS file. Would be great to see this changed.

[bartlomieju]

@kitsonk is this issue actionable after the compiler refactors?

[kitsonk]

Worth testing that it doesn't cause problems. It shouldn't now, but we don't specifically test for it.