tc39 / proposal-defer-import-eval

A proposal for introducing a way to defer evaluate of a module
https://tc39.es/proposal-defer-import-eval
MIT License
208 stars 12 forks source link

Alternative import attribute name to express lack of guarantee #6

Open acutmore opened 3 years ago

acutmore commented 3 years ago

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 };
codehag commented 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.

Jack-Works commented 3 years ago

It should be less length in words for example just "lazy"

codehag commented 3 years ago

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.

codehag commented 3 years ago

(also, the above applies to "preferLazy", but I think we should consider everything) -- feel free to make a pr with that one too.

Jack-Works commented 3 years ago

So what about defer import { } from 'str'?

codehag commented 3 years ago

also a possibility! probably better than lazy import ...

codehag commented 3 years ago

Reopening so we can keep bikeshedding. If you folks don't open prs then I will add them on monday.

ethanresnick commented 10 months ago

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

justinfagnani commented 2 months ago

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.