Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ES6 instantiation fixes #209

Closed
guybedford opened this issue Sep 30, 2014 · 4 comments
Closed

ES6 instantiation fixes #209

guybedford opened this issue Sep 30, 2014 · 4 comments

Comments

@guybedford
Copy link
Member

@guybedford
Copy link
Member Author

The assumption is that Reflect.isModule will not be provided. The first point above is not possible without Reflect.isModule.

Teverse interop is simplified through 6to5's compilation output though.

@guybedford
Copy link
Member Author

For the second point above, this is better handled by having 6to5s compilation of CommonJS and then ignoring __esModule. Closing until this becomes a real issue though.

@guybedford
Copy link
Member Author

Reopening - we need ES6 modules to be interchangeable with transpiled ES6 into CommonJS in order to have an interop story where we publish both CommonJS and ES6 and expect the same results. Now that 6to5 adds the __esModule flag, handling this is necessary to maintain consistency.

Previously I was happy to accept that the flattening of exports onto the base-level module does avoid the need to detect this flag in SystemJS, but there is one edge case:

export var p = 5;
export default 'test';

Transpiles to:

exports.p = 5;
exports.default = 'test';
exports.__esModule = true;

If I then do:

import test, {p} from 'test';

and run the above code in SystemJS with export flattening implemented against the transpiled module for test, I will get { p: 5, default: 'test', __esModule: true } as the default import for test (instead of 'test') with p being the right value.

The edge case is thus specifically for the default export when shared with named exports, but is a big enough edge case that we absolutely do need to handle the flag.

@guybedford guybedford reopened this Feb 15, 2015
@guybedford
Copy link
Member Author

Moved to #359, patch to follow shortly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant