Feature: Conditional imports

[GeoffreyBooth]

Node should provide an ESM equivalent of:

if (process.env.DEBUG)
  var { inspect } = require('util');

In other words, let users tell Node to potentially not load modules or module exports into memory, if they might not be used.

Use case 41.

[benjamingr]

Note that from reading about it it doesn't look like top-level await which is what we discussed last time is going to happen.

Then again, this can be done with dynamic import syntax. The problem is dynamic imports are contagious.

[MylesBorins]

What gave you the impression that top level await is not going to happen? Spec text is being worked on and it is being brought to tc39 again this week

…

On Sun, May 20, 2018, 5:33 AM Benjamin Gruenbaum ***@***.***> wrote: Note that from reading about it it doesn't look like top-level await which is what we discussed last time is going to happen. Then again, this can be done with dynamic import syntax. The problem is dynamic imports are contagious. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#113 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAecV3sw3qZKCdkC-P8aSlynG3Y1Eiu5ks5t0ThcgaJpZM4UF7V3> .

[devsnek]

there are also some other plans for conditional imports which don't rely on top-level await and some other interesting things like import fallbacks and stuff. afaik no one has made any official proposals yet but its definitely being discussed.

[benjamingr]

@MylesBorins

What gave you the impression that top level await is not going to happen?

Well, I was the under the impression it means late bindings for modules which I thought were a no-go.

Would love to learn more about the current status.

Spec text is being worked on and it is being brought to tc39 again this week

That's awesome 🎉

[ljharb]

The relevant thing tho is that if it becomes possible in the language, it will automatically be possible in nade - and if it doesn’t, it will be impossible. I’m not sure this issue is directly actionable in node (beyond pursuing changes in TC39)

[benjamingr]

The relevant thing tho is that if it becomes possible in the language, it will automatically be possible in nade - and if it doesn’t, it will be impossible. I’m not sure this issue is directly actionable in node (beyond pursuing changes in TC39)

If it becomes possible in the language - then by definition JS will have late bindings which resolves both the CommonJS named exports issue and the "conditional imports" issue.

That's a huge fundamental impact for modules IMO.

Moreover, this gives the commitee a chance to find a solution that's a middle-way, for example the proposal's "no exports from modules with top-level await" or "no exports after an await in modules with top-level await" which would solve one issue but not the other.

[ljharb]

I don’t see how top-level await enables late bindings such that named imports from CJS could work; could you elaborate?

[benjamingr]

I don’t see how top-level await enables late bindings such that named imports from CJS could work; could you elaborate?

First of all - Keep in mind that it's entirely possible I'm misunderstanding the issue entirely 😅

import foo from './somefile'

await somePromiseThatMightNeverSettle();

export const bar = 5;

Here, bar is only exported if the promise settles IIUC.

[ljharb]

I’m pretty sure the 5 is only exported then; but the name “bar” would be exported immediately with a value of undefined, just like a hoisted variable.

[benjamingr]

I’m pretty sure the 5 is only exported then; but the name “bar” would be exported immediately with a value of undefined, just like a hoisted variable.

Ah, so just to clarify - all the exports from top-level-awaited code would be exported immediately regardless but their values would only be updated at a later point?

[devsnek]

@benjamingr es modules already do that. they populate exports during instantiation and then evaluation actually defines the values of those exports. (except for functions, those are available right after instantiate) but anywau the only difference with top level await is that evaluation might take a bit longer.

@ljharb iirc trying to access bar before it gets its value should throw a reference error. (but a var would be undefined)

[ljharb]

@devsnek sure, I’ll buy the tdz error :-) but that’s still an early static binding, like everything else.

[benjamingr]

@benjamingr es modules already do that. they populate exports during instantiation and then evaluation actually defines the values of those exports.

Right, but without top-level await is there a way to tell the difference between the two?

Thanks a lot for explaining by the way @ljharb @devsnek, this makes a lot more sense now that I understand it's hoisting rather than late bindings.

[ljharb]

export let foo;
setTimeout(() => { foo = 3; });

altho that wouldn’t give a tdz, i believe.

[devsnek]

@ljharb i get tdz testing that

> const x = new vm.Module('export let foo; setTimeout(() => { foo = 3; });');
undefined
> void x.link(() => 0)
undefined
> x.instantiate()
undefined
> x.namespace
[Module] { foo: <uninitialized> }
> x.namespace.foo
ReferenceError: foo is not defined

[guybedford]

@devsnek did you mean to execute in your example above? TDZ only appears when dealing with circular references in ES modules, and definitely comes up in those cases as you can access a binding before it is evaluated. Simplest example would be x.mjs: import * as self from ./x.mjs’; console.log(self.p); export let p = 5; Via node —experimental-modules x.mjs

…

On Mon, 21 May 2018 at 14:46, Gus Caplan ***@***.***> wrote: @ljharb <https://github.com/ljharb> i get tdz testing that > const x = new vm.Module('export let foo; setTimeout(() => { foo = 3; });');undefined> void x.link(() => 0)undefined> x.instantiate()undefined> x.namespace [Module] { foo: <uninitialized> }> x.namespace.fooReferenceError: foo is not defined — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#113 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAkiylrOTIosX0fB3pOO4hbiAbzjFSnsks5t0rcxgaJpZM4UF7V3> .

[guybedford]

Sorry I mean ‘self.p’ in the above not ‘x.p’

…

On Mon, 21 May 2018 at 14:52, Guy Bedford ***@***.***> wrote: @devsnek did you mean to execute in your example above? TDZ only appears when dealing with circular references in ES modules, and definitely comes up in those cases as you can access a binding before it is evaluated. Simplest example would be x.mjs: import * as self from ./x.mjs’; console.log(x.p); export let p = 5; Via node —experimental-modules x.mjs On Mon, 21 May 2018 at 14:46, Gus Caplan ***@***.***> wrote: > @ljharb <https://github.com/ljharb> i get tdz testing that > > > const x = new vm.Module('export let foo; setTimeout(() => { foo = 3; });');undefined> void x.link(() => 0)undefined> x.instantiate()undefined> x.namespace > [Module] { foo: <uninitialized> }> x.namespace.fooReferenceError: foo is not defined > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub > <#113 (comment)>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AAkiylrOTIosX0fB3pOO4hbiAbzjFSnsks5t0rcxgaJpZM4UF7V3> > . >

[devsnek]

@guybedford ah sorry I thought we were taking about pre-evaluate. nice example.

[ljharb]

No JS in that graph can run pre-evaluate, that’s the whole point/problem :-p

[guybedford]

That is by definition I think :)

…

On Mon, 21 May 2018 at 15:00, Jordan Harband ***@***.***> wrote: No JS can run pre-evaluate, that’s the whole point/problem :-p — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#113 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAkiyptJKBDB2p4Kb_BhaQrsQOYNVKBaks5t0rpWgaJpZM4UF7V3> .