follow up about ecmascript-more-export-from

[leebyron]

Thanks so much for reading the spec and writing up this detailed feedback! I added some bits to the README to cover some of the edge cases this proposal enables including export default from "mod", so hopefully that helps. I also just pushed up the (presumably) finished spec text in Spec.md which might help answer techincal-level questions.

is export * as foo from ... a footgun?

I'm not sure it's a footgun. Maybe I don't understand the performance concerns well enough. If it is a footgun and there's consensus that this is not a pattern we want to encourage then I would propose that we should remove import * as foo from the spec. That seems probably really unlikely at this point. So my argument here is that there is value here and the footgun really already exists with import * as foo (if it is a footgun), and the short-form syntax for import * as foo; export {foo} isn't making the footgun enough more dangerous to warrant the surprising asymmetry between import from and export from.

is export default from "foo" too confusing?

I think the fact that most export default forms create local bindings is below the level of detail the vast majority of people will consider. Those who do consider it are unlikely to be confused. I think this export-default statement reads pretty clearly in what it does. It's a special case of the export x from "foo" where x happens to be default which happens to do what we expect. I don't think is any more confusing than import x from "foo".

I should say - I think the difference between import x from "foo" and import {x} from "foo" is already going to be lost on most. It's a little bit like destructuring, but not quite. Point being, most potential confusion is already there in ES6 modules. This proposal should really be a net-win on confusion by improving a valid symmetry.

refactor scenarios

I'm not sure I understand what you're trying to say here. I agree that refactoring is a bummer, but I'm not sure if you're trying to say this spec will help or hinder refactoring efforts.

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

Totally. This proposal would enable that!

implementation details

Check out the spec I wrote up. It includes AST details as well as the semantics they translate to. I'm actually really happy after reading this Spec doc next to the "Imports" Spec in ES6. The purpose of this proposal was to improve symmetry between import from and export from and in fact the symmetry extends all the way to AST and parser semantics. I'll be surprised if it's difficult to implement.

I can probably help you with that in the next few days.

So awesome! I'm interested in getting this in as many tools as possible so we can start getting real feedback. The TC39 room pretty unanimously recommended that I write spec, implement transpilation, and collect user feedback before May's meeting so I can take all the help I can get!

[leebyron]

And I suspect that this case will be a little bit more complicated to implement in espree, esprima, etc..., we will see.

I think I understand what you're getting at here. You're worried about the ambiguity between:

export default from "mod"

and

var from = 42;
export default from;

where from is a local identifier and thus a valid AssignmentExpression, correct?

I'm open to feedback on how to represent the spec AST to clarify this point. It will probably require a lookahead to determine if it's the export v from "mod"; form.

[leebyron]

Landed 7732162 as one way to solve the grammatical ambiguity but open to ideas.

This would make this a syntax error:

var from = 42;
export default from;

Which is maybe not awful, but not the best.

[arv]

I also ran into the export default from 'module' issue when I implemented this [1]. I naïvely thought it would just work.

The lookahead restriction seems reasonable to me (not optimal but a good compromise).

google/traceur-compiler#1843

[caridy]

You're worried about the ambiguity between:

Ha, I thought that export default from was going to be a hard cookie to swallow, but your solution seems simple enough, I never thought about extending lookahead ;)

I'm not sure it's a footgun. Maybe I don't understand the performance concerns well enough.

I should have explained better. Two implications:

• the exotic namespace object throws (or was supposed to throw) when trying to access or set props, although that has changed last week (I think you were in the meeting in paris). I'm glad that restriction was removed, otherwise passing those exotic objects around was going to be a big pain, and a huge refactor hazard. But I didn't know about this decision at the time I commented ;), so this is not longer an issue.
• users can (and will) do the extreme, like foo.bar.x.y where all of them are really exotic namespace objects exported in different levels, imagine how expensive will be to access y. This is probably just me and my paranoia about perf.

If it is a footgun and there's consensus that this is not a pattern we want to encourage then I would propose that we should remove import * as foo from the spec. That seems probably really unlikely at this point. So my argument here is that there is value here and the footgun really already exists with import * as foo (if it is a footgun), and the short-form syntax for import * as foo; export {foo} isn't making the footgun enough more dangerous to warrant the surprising asymmetry between import from and export from.

As for the footgun reference, really the principle here is to avoid providing sugar for structures that we consider bad, but that doesn't mean we will drop the lower level structures. The example of import * as foo; export {foo} is a good one, which clearly allows them to create multiple levels of namespaces (e.g.: foo.bar.x.y), but they will have a hard time doing so, which is a hint that they are doing something wrong :). DH: "Make the common cases easy and the uncommon cases possible."

If we want to move those functions into separate files, it will probably look like this:
Totally. This proposal would enable that!

Yes, that's what I was trying to hint ;), that the basic refactor flow seems to work well.

Btw, compound examples are looking good as well. I will do a pass on https://github.com/leebyron/ecmascript-more-export-from/blob/master/Spec.md tonight.

[leebyron]

Awesome!

Also, @sebmck has already gotten a version based on this proposal in the experimental branch of babel - babel/babel@afe8792

[leebyron]

As for the footgun reference, really the principle here is to avoid providing sugar for structures that we consider bad, but that doesn't mean we will drop the lower level structures.

I agree with this philosophy. I'm curious about the performance implications of accessing a name-space exotic object. I hope that this is a unnecessary concern or at least a territory for VM optimization to cover down the line.

[jasonkuhrt]

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.

Link: https://esdiscuss.org/topic/re-export-default

Off-topic: The only other gripe left after this would revolve around allowing imported namespaces to be merged wholesale into scope, with additionally pick or omit semantics for granular control. Haskell allows for this and its really quite nice I think. I've heard OCaml has also interesting features but I'm not familiar with them.

[gaearon]

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.

I also bumped into this and even thought this was a bug in Babel.