Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Alternative import attribute name to express lack of guarantee #6

Open
acutmore opened this issue Jan 30, 2021 · 9 comments
Open

Alternative import attribute name to express lack of guarantee #6

acutmore opened this issue Jan 30, 2021 · 9 comments

Comments

@acutmore
Copy link
Contributor

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 };
@acutmore acutmore changed the title Alternative import attribute name Alternative import attribute name to express lack of guarantee Jan 30, 2021
@codehag
Copy link
Collaborator

codehag commented Jan 30, 2021

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.

acutmore added a commit to acutmore/proposal-defer-import-eval that referenced this issue Jan 30, 2021
Adds 'preferLazy' and 'lazyHint' alternatives from tc39#6
@codehag codehag closed this as completed Jan 30, 2021
@Jack-Works
Copy link
Member

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

@codehag
Copy link
Collaborator

codehag commented Jan 31, 2021

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
Copy link
Collaborator

codehag commented Jan 31, 2021

(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
Copy link
Member

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

@codehag
Copy link
Collaborator

codehag commented Jan 31, 2021

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

@codehag codehag reopened this Jan 31, 2021
@codehag
Copy link
Collaborator

codehag commented Jan 31, 2021

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

@ethanresnick
Copy link

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
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants