`import *` potentially doesn't need to parse/link

[bmeck]

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]

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]

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]

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.