Interaction with `export * from`

[nicolo-ribaudo]

Consider this example:

// entrypoint.js
import { foo } from "./a.js";

// a.js
export * from "./b.js";

// b.js
export defer { foo } from "./foo.js";
export defer { bar } from "./bar.js";

Will it load bar.js? We have two possible answers:

• Yes: export * from is loading all the bindings from ./b.js, so it's loading bar. It's equivalent to export { foo, bar } from
• No: The bar binging is not actually listed anywhere. Deferred re-exports are only loaded when the relative binding is explicitly present in a { ... } from list.

[guybedford]

What if a.js was instead:

export { foo, bar } from './b.js'

Would the same question apply?

[nicolo-ribaudo]

In theory we could ask the same question, but I would answer with "both are loaded" so that it keeps matching import { foo, bar } from './b.js'; export { foo, bar }.

[guybedford]

And in import { foo, bar } from './b.js'; export { foo, bar } as well, does the deferred status of the reexport get inferred from the transitive dependency?

[guybedford]

Spoke to soon, of course that case exposes the local binding so is executed, which makes sense.

So equating export * from './b.js' and export { foo, bar } from './b.js seems fine, but equating import { foo, bar } from './b.js'; export { foo, bar } creates local bindings inhibiting deferral.

Your argument of choosing to equate export { foo, bar } from './b.js' with import { foo, bar } from './b.js'; export { foo, bar } thus doesn't seem a straightforward one, and seems to load the answer? Why would we equate these?

[guybedford]

Basically the question is - do we ever treat deferral as a binding property and not a direct syntax property, and is there reason to pick one over the other? I can see arguments for both sides here.

Perhaps we have to think about what is going to ensure users get the benefits of deferral. This question can go both ways two:

• Tell users defer is always explicit, so they put it everywhere. Maybe export defer * from './foo' syntax becomes a thing so there's no ambiguity.
• Make defer as transitive as possible, once something is defer it remains defer without further action to ensure the best performance. export { a } from './b' automatically detects and applies transitive deferral. Without users having to fully understand the defer semantics, the best defer semantics apply.

[nicolo-ribaudo]

I don't like export defer * from './foo' because it makes me think "only load ./foo if that module is used", which would not be what it does.

Make defer as transitive as possible, once something is defer it remains defer without further action to ensure the best performance. export { a } from './b' automatically detects and applies transitive deferral. Without users having to fully understand the defer semantics, the best defer semantics apply.

That's also a possible way forward. Right now I was thinking that "whenever you explicitly write the name of a module's export, you are causing it to be loaded". I need to check how complex it would be to do (right now it's really nice that you don't need to iterate down export { ... } thing declarations, and only export defer { ... } ones).

[guybedford]

I don't like export defer * from './foo' because it makes me think "only load ./foo if that module is used", which would not be what it does.

This makes sense to me, but then seems like a strong argument for ensuring defer does the smartest lazy thing as discussed.

I need to check how complex it would be to do (right now it's really nice that you don't need to iterate down export { ... } thing declarations, and only export defer { ... } ones).

Would be great to get a sense for this further.

[nicolo-ribaudo]

I need to check how complex it would be to do (right now it's really nice that you don't need to iterate down export { ... } thing declarations, and only export defer { ... } ones).

So, I don't have an example of what the spec text would look like because it's actually quite complex to do. It means that in this example:

// entrypoint.js
import { foo } from "./a.js";

// a.js
export { foo, bar } from "./b.js";

// b.js
export defer { foo } from "./c.js";
export defer { bar } from "./d.js";

when loading the imports of ./entrypoint.js we need to not only load ./a.js and it's dependencies, but also iterate through ./a.js's re-exports to see if any of then recursively contains an export defer. Right now we only do this recursion if export is explicitly marked as defer, while do do this change we would need to always do it.

It means that it's causing a performance regression for those that do not use export defer, for whom it is not offset by the cost of not loading/executing some modules.

---

I'm leaning towards not changing the behavior of export { ... } from, and making export * from "./somewhere.js" cause a pre-load of all the files referenced by ./somewhere.js (as if you were doing export * as ns from "./somewhere.js).

[nicolo-ribaudo]

Actually, doing this change would greatly help with adoption of export defer, because it means that you don't have to convert the whole chain adding the defer modifier (which is basically the CJS->ESM adoption problem).

[nicolo-ribaudo]

I opened #9 with a draft change for #5 (comment), but I'm starting to think that it would be a bad change (description in the PR).

Actually, doing this change would greatly help with adoption of export defer, because it means that you don't have to convert the whole chain adding the defer modifier (which is basically the CJS->ESM adoption problem).

While it's true that it would help with making adoption effective more quickly, the comparison with ESM/CJS is not actually good, because you don't have the problem where you can only start migrating from the top of the tree.

Dependencies can start adding defer even if their dependents aren't getting the maximum benefits out of them. Additionally, usually you use export ... from when re-exporting from your own files and not from a dependency, so you would migrate the whole library at the same time and already get the maximal benefit.

[nicolo-ribaudo]

Suggestion from @JakobJingleheimer: what if it was an error to export-from an export-defer-from?

[nicolo-ribaudo]

Pr for @JakobJingleheimer's suggestion: #10

[nicolo-ribaudo]

I'm closing this issue as we are not doing the "implicit propagation". I will present however #10 in plenary asking committee feedback about it.