Skip to content

Instantly share code, notes, and snippets.

@calvinmetcalf
Last active August 29, 2015 14:02
Show Gist options
  • Star 1 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save calvinmetcalf/9252f41bf6e3c8b4add7 to your computer and use it in GitHub Desktop.
Save calvinmetcalf/9252f41bf6e3c8b4add7 to your computer and use it in GitHub Desktop.

There are three cases of module imports,

  • all the that were exported
  • some of the names that were exported
  • just the default export

just because the language differentiates them doesn't mean that they need to be treated differently, for example something like the following would likely be much more cohesive.

syntax ala let {foo, bar} = import 'library':

  1. if import 'library' isn't at the top level through a syntax error*
  2. if library has a default export then treat import 'library' like a function that returns the default export
  3. if library doesn't have a default export
    1. if the left hand side has destructuring then do static analysis on the names and import them
    2. if it does't then treat import 'library' like a function that returns a module object

*or not, the pitfalls of conditional loading seemed to be a sticking point for some people but from my experience with browserify being able to use an if statement for statically analyzed imports makes cross module system support via UMD doable

@cscott
Copy link

cscott commented Jun 16, 2014

I'm sympathetic to the argument that this should be:

import {foo, bar} from "library";

instead of a standard let statement, to reflect the fact that these are actually magical mutable bindings in some cases. Both other than that syntactic tweak, I agree with your behavior suggestions 1-3.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment