-
Notifications
You must be signed in to change notification settings - Fork 12
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
Comments
I like |
Adds 'preferLazy' and 'lazyHint' alternatives from tc39#6
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 |
(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 |
also a possibility! probably better than |
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 In #27, I proposed |
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:
The text was updated successfully, but these errors were encountered: