tc39
Alternative import attribute name to express lack of guarantee
As there is no guarantee that the imported module is evaluated lazily, e.g. it has already been evaluated, or it contains top level await. Perhaps a name that more clearly expresses this is a hint rather than an assertion would work better?
Bikeshed:
import {x} from "y" with { preferLazy: true };
import {x} from "y" with { lazyHint: true };
I like preferLazy! That communicates it pretty well. Feel free to add this (both really) to the bikeshedding doc (closer to the top, the bottoms ones are a bit more unsure...). I can also add it on monday.
It should be less length in words for example just "lazy"
We can also consider it, In fact, that would be ideal! I already ran into issues with people confusing this proposal with lazy loading -- a process which must be async. This is why the proposal name change from "lazy modules" to "defer module evaluation". I suspect that lazy on it's own will be too overloaded a term to be precise here.
(also, the above applies to "preferLazy", but I think we should consider everything) -- feel free to make a pr with that one too.
Reopening so we can keep bikeshedding. If you folks don't open prs then I will add them on monday.
I'm a strong 👍 on some name that communicates that there's no guarantee here. As I mentioned in #27, I don't think it's surprising that a deferred import can't prevent the evaluation of a module if it needed to be evaluated non-lazily elsewhere in the module graph, but I do think handling of top-level await is potentially confusing.
In #27, I proposed partialDefer or deferSync
I thought that import attributes would be a natural fit for this feature. I think it would be good to at least address in the proposal why there is new syntax instead of using import attributes.
