This spec has been withdrawn in favor of the equivalent micro-proposals: export ns from and export default from.

---

Additional export-from statements in ES7

ES7 Proposal

Stage: 1

Author: Lee Byron

Specification: Spec.md

AST: ESTree.md

Transpiler: See Babel's es7.exportExtensions option.

Problem statement and rationale

The export ___ from "module" statements are a very useful mechanism for building up "package" modules in a declarative way. In the ES6 spec, we can:

• export through a single export with export {x} from "mod"
• ...optionally renaming it with export {x as v} from "mod"
• We can also spread all exports with export * from "mod".

These three export-from statements are easy to understand if you understand the semantics of the similar looking import statements.

However, there are other import statements which would have very useful export-from forms.

• Exporting the ModuleNameSpace object as a named export: export * as ns from "mod"
• Forwarding the default export of the referenced module as a named export of this module: export v from "mod"

Current ES6 Modules:

Import Statement Form	[[ModuleRequest]]	[[ImportName]]	[[LocalName]]
import v from "mod";	"mod"	"default"	"v"
import * as ns from "mod";	"mod"	"*"	"ns"
import {x} from "mod";	"mod"	"x"	"x"
import {x as v} from "mod";	"mod"	"x"	"v"
import "mod";

Export Statement Form	[[ModuleRequest]]	[[ImportName]]	[[LocalName]]	[[ExportName]]
export var v;	null	null	"v"	"v"
export default function f(){};	null	null	"f"	"default"
export default function(){};	null	null	"*default*"	"default"
export default 42;	null	null	"*default*"	"default"
export {x};	null	null	"x"	"x"
export {x as v};	null	null	"x"	"v"
export {x} from "mod";	"mod"	"x"	null	"x"
export {x as v} from "mod";	"mod"	"x"	null	"v"
export * from "mod";	"mod"	"*"	null	null

Proposed additions:

Export Statement Form	[[ModuleRequest]]	[[ImportName]]	[[LocalName]]	[[ExportName]]
export * as ns from "mod";	"mod"	"*"	null	"ns"
export v from "mod";	"mod"	"default"	null	"v"

Symmetry between import and export

There's a syntactic symmetry between the export-from statements and the import statements they resemble. There is also a semantic symmetry; where import creates a locally named binding, export-from creates an export entry.

As an example:

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.

The two proposed additions follow this same symmetric pattern:

Exporting a namespace exotic object without altering local scope:

// proposed:
export * as ns from "mod";
// symmetric to:
import * as ns from "mod";

Re-exporting a module's default export with a name:

// proposed:
export v from "mod";
// symmetric to:
import v from "mod";

Using the terminology of Table 42 in ECMA-262 v6 RC4, the export-from form can be created from the symmetric import form by setting export-from's [[ExportName]] to import's [[LocalName]] and export-from's [[LocalName]] to null.

Table showing symmetry

Statement Form	[[ModuleRequest]]	[[ImportName]]	[[LocalName]]	[[ExportName]]
import v from "mod";	"mod"	"default"	"v"
export v from "mod";	"mod"	"default"	null	"v"
import * as ns from "mod";	"mod"	"*"	"ns"
export * as ns from "mod";	"mod"	"*"	null	"ns"
import {x} from "mod";	"mod"	"x"	"x"
export {x} from "mod";	"mod"	"x"	null	"x"
import {x as v} from "mod";	"mod"	"x"	"v"
export {x as v} from "mod";	"mod"	"x"	null	"v"
import * from "mod"	"mod"	null	null (many)
export * from "mod";	"mod"	"*"	null	null (many)

Note: import * from "mod" is only included for illustrative purposes. It is not in existing spec or part of this proposal.

Compound export-from statements

This proposal also includes the symmetric export-from for the compound imports:

// proposed
export v, {x, y as w} from "mod"
// symmetric to
import v, {x, y as w} from "mod"

As well as

// proposed
export v, * as ns from "mod"
// symmetric to
import v, * as ns from "mod"

Export default from

One use case is to take the default export of an inner module and export it as the default export of the outer module. This is written as:

export default from "mod";

This is not additional syntax above what's already proposed. In fact, this is just the export v from "mod" syntax where the export name happens to be default. This nicely mirrors the other export default ____ forms in both syntax and semantics without requiring additional specification. An alteration to an existing lookahead restriction is necessary for supporting this case.