Optional Module Name Enumeration

[Nathan Hammond]

Given this proposal it's entirely possible to have code of the type:

function getUserInput() {
  return Math.random();
}
let moduleName = getUserInput();
import(moduleName);

This is fantastic for programming user ergonomics and literally impossible to do anything with tooling-wise for ahead-of-time optimization (which impacts the programming user's experience). The options I see here to make it possible to do AOT optimizations are:

1. Discourage use of this feature. (Not ideal.)
2. Leverage comments as a secondary information channel to any tooling. (Not ideal, but will work just as well as encoding it into the dynamic import itself for AOT tools.)
3. Add additional (optional) annotation features into the import function. Can be used as a must-be-satisfied constraint for security benefits as well. (Also not entirely ideal because of increased API surface area, but maybe worth it?)

I'd like to propose modification to allow for option three above:

import(moduleName, ['allowed', 'also-allowed']);

I'm on @ember-cli/core; we care about the outcome of this discussion. 😄

[Domenic Denicola]

It's a non-goal of this proposal to support AOT tools which reinterpret module syntax with different semantics (e.g., bundling or transpiling). This proposal is meant for engines to implement to allow dynamic module loading.

I'd encourage tools who want to reinterpret module syntax with different semantics to come up with their own shared solutions for embedding the additional data needed to make their nonstandard semantics work---in the tooling space. Comments sound pretty good to me, or package.json fields, or whatever. But we won't be coding such conventions into the language. They're inherently nonstandard, and not destined to become part of the standard.

I'm going to close this as it won't lead to any actionable change to the proposal. I'm happy to continue discussing in the closed thread, but I'd suggest instead discussing it in the repo of whatever tooling (e.g. ember-cli) that plans to implement these nonstandard semantics.

[Nathan Hammond]

Given your stated goals I don't consider my feedback to be particularly actionable. However, I do believe that the "security issue" (finger quotes, it may be a bit far-fetched) may be worth addressing in runtime code? The ability to insert a different JS file than was expected which can have different named or default exports could be a fun new attack vector.

[Domenic Denicola]

Yeah, that's definitely a fun attack vector, but it's not new :). CSP is on top of covering that pretty well.