Open acutmore opened 3 years ago
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"
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.
So what about defer import { } from 'str'
?
also a possibility! probably better than lazy import ...
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.
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: