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

import * potentially doesn't need to parse/link #9

Open
bmeck opened this issue Jan 31, 2021 · 3 comments
Open

import * potentially doesn't need to parse/link #9

bmeck opened this issue Jan 31, 2021 · 3 comments

Comments

@bmeck
Copy link
Member

bmeck commented Jan 31, 2021

Given that there is no linkage required required for import * likely it can avoid parsing or linkage if cycles are not present in some way. The only issue is with behaviors that can statically cyclically link:

// a
import 'b' with {layzInit: true};
// b
export * from 'a';

This would let things be done in an even more controlled manner but would need some kind of guard against cycles. Either stating a different kind of linkage or disallowing cycles to modules with lazy behaviors.

It would be good to at least investigate here as ahead of time fetch costs are some of the prohibitive costs still possible with this proposal.

@Jack-Works
Copy link
Member

But we need to throw syntax error or early errors before we run the code. It will be super strange to throw a syntax error at the time of your first visit to the deferred imports.

@codehag
Copy link
Collaborator

codehag commented May 25, 2022

One thing I am discussing with various delegates is just how critical early errors are. Do they really add to developer experience if they are at parse time as opposed to execution time? Don't we already have this with dynamically loaded modules, as parse is deferred anyway?

@nicolo-ribaudo nicolo-ribaudo mentioned this issue Sep 11, 2023
10 tasks
@nicolo-ribaudo
Copy link
Member

nicolo-ribaudo commented Mar 22, 2024

The proposal moved in a direction that still requires parsing the graph ahead-of-time, to detect top-level await. However, I presented a couple months ago a new feature (see #30/#31) that actually allows skipping loading of provably unused code through re-exports.

For now let's keep early errors as eager since some delegates expressed that preference, but they could easily be delayed to execution in the future. Due to the current nature of the proposal, where deferred imports are only through namespace imports, I don't think the "cyclical binding" linking error is a problem anymore.

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

4 participants