The export ___ from "module" statements are a very useful mechanism for
building up “package” modules in a declarative way. In the ECMAScript 2015 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 is an import statement which does not have corresponding
export-from statement, exporting the ModuleNameSpace object as a named export.
Example:
export someIdentifier from "someModule";export someIdentifier, { namedIdentifier } from "someModule";
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 existing example:
import {v} from "mod";
If then v should be exported, this can be followed by an export. However, if
v is unused in the local scope, then it has introduced a name to the local
scope unnecessarily.
import {v} from "mod";export {v};
A single “export from” line directly creates an export entry, and does not alter
the local scope. It is symmetric to the similar “import from” statement.
export {v} from "mod";
This presents a developer experience where it is expected that replacing the
word import with export will always provide this symmetric behavior.
However, when there is a gap in this symmetry, it can lead to confusing behavior:
“I would like to chime in with use-case evidence. When I began using ES6 (via
babel) and discovered imports could be re-exported I assumed the feature set
would be symmetrical only to find out quite surprisingly that it was not. I
would love to see this spec round out what I believe is a slightly incomplete
feature set in ES6.”
@jasonkuhrt
“I also bumped into this and even thought this was a bug in Babel.”
@gaearon
Proposed addition:
The proposed addition follows this same symmetric pattern:
Importing the “default” name (existing):
import v from "mod";
Exporting that name (existing):
import v from "mod";export {v};
Symmetric “export from” (proposed):
export v from "mod";
Compound “export from” statements:
This proposal also includes the symmetric export-from for the compound imports:
Importing the “default” name as well as named export (existing):
import v, { x, y as w } from "mod";
Exporting those names (existing):
import v, { x, y as w } from "mod";export { v, x, w };
Symmetric “export from” (proposed):
export v, {x, y as w} from "mod";
Note: The compound form must also support export-ns-from should both proposals be accepted:
export v, * as ns from "mod";
Exporting a default as default:
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 can be written as:
export default from "mod";
This is symmmetric to the (existing) import form:
import default from "mod";export { default };
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.
Common concerns:
Do we need this even through you can already do this with export { default } from "mod"?
Yes! It is true that you can already “export from” a module’s default export
without altering the local scope:
export { default } from "mod";
You can even rename the default:
export { default as someIdentifier } from "mod"
There is a benefit to this, it’s explicit and it is symmetric with the
“import” form:
import { default as someIdentifier } from "mod"
However the purpose of this proposal is not to enable a new use case, the
purpose is to provide an expected syntactic form which currently does not exist,
and which favors the “default” export.
That “import” example is not often typed, as there is a preferred shorter syntax:
import someIdentifier from "mod"
This proposal argues that a similar shorter syntax should also exist for a
symmetric “export from” form:
export someIdentifier from "mod"
Table showing symmetry
Using the terminology of Table 40 and Table 42 in ECMAScript 2015, 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.