Load enhancements

[lzhoucs]

Enhance load() with options to load based on __esModule metadata either: a) default export. b) all exports except default. The default behavior is a). Existing code spreading across all other packages that depends on load() will have to update as well.

Resolves: #210

[matt-gadd]

I do wonder whether this is the correct approach for the api. isDefault (which I think should be named hasDefault if staying as is), can only be set for all the modules as load can take more than 1 mid, which seems inflexible. It seems like load should perhaps be left as is today, and only care about actually requiring the module.

Would it be nicer to have a functional utility(s) that you can use after load, to pick the defaults out? Something like:

for all modules:

load('a', 'b', 'c')
    .then(useDefault)
    .then(([ a, b, c ]) => {
        // done 
    });

for specific modules:

load('a', 'b', 'c')
    .then(([ a, b, c ]) => [ a, useDefault(b), c ])
    .then(([ a, b, c ]) => {
        // done
    });

it also means we don't have to do any annoying additional argument shifting/swapping due to the multiple load function overloads.

[dylans]

While in the context of this topic, it may be worth looking into imports() which is now stage 3, which is tracked in #202?

[matt-gadd]

@dylans I don't believe we can implement imports here in dojo/core. Mainly due to us needing a contextual require to work with relative paths for AMD so we can't match the signature of imports. The imports topic is probably a larger discussion in dojo/meta and dojo/loader.

[dylans]

@matt-gadd ok, I will move the core issue to meta and add your comment there.

[lzhoucs]

Thanks! I do like Matt's idea and Rory's solution better! The solution is simpler and more flexible.