Symmetry between import and export about ecmascript-more-export-from HOT 10 CLOSED

The export-from syntax does not create a local binding, making it different importing and re-exporting. A primary use-case for export-from is to define a top-level package module for a library. Here's an example, this happens to also import and re-export a function because the package module is also calling a function it's re-exporting.

As for the change in Babel 6 for how ES modules are compiled to CJS, this is to support the live bindings and circular dependencies features of ES modules. When Babel compiles a ES module that uses export-from to a CJS require() it will do so using Object.defineProperty to create getters which reference the value from the binding that's being re-exported. This means that the default export has to be a property on an object in order for Babel to generate a getter, e.g.

a.js

export default 42;

b.js

export {default} from './a.js';

Babel 6 will compile b.js to this CJS code:

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

Object.defineProperty(exports, 'default', {
  enumerable: true,
  get: function get() {
    return a['default'];
  }
});

from ecmascript-more-export-from.

ok I kinda understand that. It's definitely a good reason I hadn't considered 👍

But still I wonder, why not make the variable available in the local scope as well?

from ecmascript-more-export-from.

Thanks for the comment. I added more detail when refactoring into micro-proposals:
https://github.com/leebyron/ecmascript-export-ns-from

To address some of your questions, I believe many of these are small typing mistakes or perhaps babel issues:

For example:

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

Should be:

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

To parse correctly. This will both import v into the local scope as well as include it in this module's exports.

And this case is totally valid, perhaps there was a parser bug?

export {x, y} from 'mod';

from ecmascript-more-export-from.

But still I wonder, why not make the variable available in the local scope as well?

The purpose of the "export from" forms is to explicitly not alter the local scope while creating "package" modules.

This proposal doesn't suggest altering the behavior of any of the existing "export from" forms, just adding additional cases that previously weren't considered.

from ecmascript-more-export-from.

@leebyron Thanks for your explanations. I still have one question:

For example:

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

Should be:

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

I don't get this. Why is this different from:

const v = 'whatever';
export v;

Why do we need to enclose v in curly braces?

from ecmascript-more-export-from.

That is because export v; is not valid syntax while export {v} is valid syntax. As I understand it, that original decision was made for two reasons: to mirror the import { v } from "mod" and to remove any ambiguity from other export ___ syntax forms.

You can read more about the existing syntax at https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/export or in the spec at https://tc39.github.io/ecma262/#prod-ExportDeclaration

from ecmascript-more-export-from.

Wow, you are fast! 👍

I am currently doing things like this in my code

export const store = createStore(
    createReducer(app),
    typeof window == 'object' && window.__data && fromJSON(window.__data) || undefined,
    storeEnhancer
);

(from a React / Redux app)

also, I'm doing this:

export const routes = (
    <Route path="/" component={App}>
        // ....
    </Route>
);

(react router config)

It works great with Babel. Is it wrong?
If not, then why would there be a difference between

export const x = 10;

and

const x = 10;
export x;

This is very confusing to me...

delves into docs

from ecmascript-more-export-from.

Mmm it seems the const sorta triggers a different path in the syntax. I guess I'm looking at export too much as if it was just a function. At least with this info I can explain some of those Unexpected token issues I've been having. Thanks very much for your helpful comments!

from ecmascript-more-export-from.

There's nothing wrong with what you're doing.

There are two primary forms of export: exporting a previously defined variable (export ExportClause) and exporting a definition as you define it (export VariableStatement and export Declaration). You can see them defined in https://tc39.github.io/ecma262/#prod-ExportDeclaration

You use exporting a definition as you define it by prefixing export to the definition:

export const x = 10;
export function doSomething() {};
export class MyClass {};

You can export previously defined variables with the ExportClause form:

export { x };
export { doSomething, MyClass };

from ecmascript-more-export-from.

@leebyron Yes it's much more clear to me now. I was using a wrong mental model of export.

from ecmascript-more-export-from.