Symmetry between import and export
...
export {v} from "mod";
Is symmetric to:

import {v} from "mod";
However, where importing v introduces a name in the local scope, export-from v does not alter the local scope, instead creating an export entry.

I don't get this. All my instincts tell me that

export {v} from 'mod';

should be equivalent to doing

import {v} from 'mod';
export v;

But I have indeed noted (via Babel) that indeed, when I do

export {v} from 'mod';

I can't actually use v later on in that code:

v.whatever();  // Uncaught TypeError: Cannot read property 'whatever' of undefined(…)

What is the rationale behind this? I am struggling with this on a regular basis. I then try to do this instead:

import {v} from 'mod';
export v;

And it complains about 'Unexpected token' on the export statement. I have many, many commits in my Git repo with all kinds of small permutations on export statements to get rid of issues that keep creeping up.

Similarly, for some reason, this breaks with 'Unexpected token':

export {x, y} from 'mod';

I have to change it to

export {x} from 'mod';
export {y} from 'mod';

Now these could be Babel issues, but I just wanted to give you this feedback from using it in practice.

I would personally expect

export {v} from 'mod';

to be equavalent to

import {v} from 'mod';
export v;

...so for v to be defined after this has run. v being undefined is unexpected for me and I wonder what it's application would be?

I would also suggest (but probably that ship has already sailed) that import and export would give interop with CJS require more priority. Until recently I could do this:

module a.js

export default function a();

module b.js

var a = require('./a');

Now, since recently, I have to do this:

module b.js

var a = require('./a').default;

According to the Babel people this was changed due to a spec change? If so I think that change is one for the worse...

Anyway... don't want to be whining. All in all I love imports and the export from syntax and I'll probably get used to whatever it turns out to be. Keep up the great work!

I'd like to suggest an additional as v extension on the import side.

The syntax would be:

import {x,y} as v from "mod";

The semantics would be to create a plain object v and populate it with properties x, y (etc.) resulting in v = {x:x, y:y} (or v = {vx:x, vy:y} if x/y are also aliased).

The reasoning is to facilitate static analysis and tree-shaking when plucking individual exports from libraries like lodash. If I import _ from "lodash"; then I get all of lodash. If I import {x, y} from "lodash"; (where x and y are specific lodash functions like debounce or omit) then a smart loader or builder can ensure that only those functions and their dependencies are included in the resulting page or build.

The current {x, y} already works, but it clutters my module with names that I'd rather encapsulate. I can use {x as _x, y as _y} (or whatever renaming scheme makes sense), but this is verbose and still produces a lot of top-level names. If I could import {x, y} as _ from "lodash"; then I'd have a top-level _ variable with everything I wanted and nothing I didn't.

Sorry, don't know where to ask question.
Is there any eslint rules that allow this export extensions?

It might be worth mentioning that the following are synonymous:

import v from "mod";
import {default as v} from "mod";

likewise, your proposed:

export v from "mod";

... has an existing form:

export {default as v} from "mod";

This is not to invalidate your argument for parity between import from and export from. Just something worth mentioning for completeness.

Should following statment both valid? same for: class, var, const, let, do I have to look ahead to tell which path to choose?

export function from "a"
export function from () {}

@leebyron thanks for putting this together. There are 3 topics we need to cover before moving forward:

area of concern

After the first pass, I have two concerns:

1. is export * as foo from ... a footgun? this is sugar to export an exotic object (the namespace object), which we don't have any restriction for it today, but I'm concern that this will encourage people to create namespaces, which we have been battling for a long time to escape from knowing that it affects perf due to the lookup process (and the getters involved in the process), e.g.:

   import * as foo from "foo";
   foo.bar.baz(); // where baz is a named export down the rabbit hole, which is what really matters.

   From the technical perspective, I don't see any issue with it though.

2. is export default from "foo" too confusing? This will be the only form of export default ... with module specifier allowed that does not define any local bindings.

refactor scenarios/refactor hazard

One very common scenario that we should try is when growing a simple package from one file to multiple files, saying:

// main.js
export function foo () { /* ... */ };
export default function () { /* ... */ }

If we want to move those functions into separate files, it will probably look like this:

// foo.js
export default function foo () { /* ... */ };

// core.js
export default function () { /* ... */ }

// main.js
export foo from "./foo";
export default from "./core";

Today, we can write that as:

// main.js
export {default as foo} from "./foo";
export {default} from "./core";

From what I can tell, I think the part that is missing in the proposal is export default from ... mostly because export default is very restrictive today, and does not allow module specifier. And I suspect that this case will be a little bit more complicated to implement in espree, esprima, etc..., we will see.

implementation details

This is mostly about EStree, and the details of how we will represent the new syntax. I can probably help you with that in the next few days. This is mostly to prevent any down the road weirdness that can be surfaced when trying to define the AST for the new declaration forms. Check: https://github.com/estree/estree/

Will this export * also skip exporting the default export?

Just in case anyone had the same issue looking for the babel "es7.exportExtensions" babel option, you can find it here. Babel has exploded into loads of tiny little modules which you now have to install manually. To enable this, you need to install the babel-plugin-transform-export-extensions and add transform-export-extensions to your plugins in your config.

Could be worth updating the README.md.

Consensus on export * as ns from "mod" and export default from "mod" as clear and useful - both should go to Stage 2. There is still concern about confusion on export v from "mod" - should stay at Stage 1.

• Split into three micro-proposals:
  • export * as ns from "mod"
  • export default from "mod"
  • export v from "mod"