Limit to representation of module?
ljharb opened this issue · comments
It seems very dangerous to have a generic syntax that allows any engine or build tool to radically change the semantics of importing a specifier based on a separate piece of information. Given that the motivating use case, as i understand it, is for WASM to provide two representations of the same module, could we impose this as a restriction in the spec?
Agreed it is critical to define evaluator attributes as altering module representation or abstraction level in the JS import API, and not the underlying loaded module syntax interpretation.
Eg for this reason this is why it is just a string and not a more complex object.
Currently the spec semantics are focused on the cache key / idempotency requirements, but definitely we should try to more carefully word this point in a way that the spec could capture - will leave this issue open to track this discussion and feature further.
I think we should clarify that this changes not how imported assets are evaluated (parsed), but rather how that parsed asset is translated into bindings exported from a module. Parsing of an asset should never be affected by an eval attribute I think.
Then maybe “evaluator attributes” is a misleading name?