Thanks to everyone for working through the issues around ModuleImport. I know
it's been frustrating, but the discussions have really helped clarify the key
constraints.
## Constraints
First, let me restate the most important arguments. In favor of removal:
* **The syntactic distinction between ModuleImport and default import is
vague.**
We've consistently seen confusion between the semantics of ModuleImport and
default export. While certainly some of the confusion might be chalked up to
misinformation and lack of documentation, we've seen people be confused by this
even when correctly explained the semantics. The problem with the syntax is
that the only visual distinction is the initial keyword (`module` vs `import`),
and it's not clear from that keyword which concept you're talking about. (Once
you've internalized the structure of module instance objects, you get a hint
from the `module` keyword, but that doesn't help people who are just learning
the system, particularly if they're already familiar with other JS module
systems.)
Against removal:
* **Without ModuleImport, authors of multi-export modules would be pressured to
circumvent the named exports functionality.**
Without ModuleImport, clients of multi-export modules have two options. Either
they use named import:
```js
import { readFile, writeFile } from "fs";
```
or if they want to explicitly namespace those functions, they have to use the
dynamic API:
```js
import "fs"; // state the dependency
var fs = this.get("fs");
```
That's inconvenient, confusing, and makes you feel like you're stepping outside
the normal usage patterns intended for the system. Since this is a choice
forced on the clients of a module, the module author will feel pressure to
circumvent the named export feature altogether and instead export a default
object with all the properties. This is bad -- it creates pressure for people
to abandon part of the module system.
## Conclusion
Here's the conclusion I've come to based on all of the above.
* **We need a form like ModuleImport.**
As many have said, clients of named-export modules need the freedom to choose
whether to explicitly namespace those imports, and they need a syntax that
doesn't feel like they've stepped outside the normal system.
* **The current syntax of ModuleImport is wrong.**
The confusion reported in developer feedback is real, and it's important.
* **The syntax should still favor default import.**
ES6 favors the single/default export style, and gives the sweetest syntax to
importing the default. Importing named exports can and even should be slightly
less concise.
* **A better ModuleImport syntax is possible, and we should settle it soon.**
I'll propose a better ModuleImport syntax below. Syntax being syntax, everyone
will of course unsheathe their bikeshed paintbrush. That's OK. The champions
will keep it from going on unbounded and help settle the debate, and we'll make
sure to capture the conclusion in the next TC39 meeting.
I do acknowledge the concerns about reopening topics for debate and delay. But
given the usability feedback, I think this case is worth fixing. We should
resolve it for ES6, perhaps in part because it's less editorial work to change
the ModuleImport production than to defer it, but more because I don't want to
delay the resolution so that implementations can ship the better syntax. But
keep in mind it doesn't matter what spec it lands in as long as implementations
are shipping it. We're still in the early days of transpiler implementations,
and there are no native implementations of modules yet. So there's time, as
long as we don't let the bikeshed go on forever. So let's get to it!
## Proposal
OK, so we're talking about a better syntax for importing a module and binding
its named exports to a variable (as distinct from importing a module and
binding its default export to a variable). Here's my proposal:
```js
import * as fs from "fs"; // importing the named exports as an object
import Dict from "dict"; // importing a default export, same as ever
```
Why is this better? Because it dovetails with the named export syntax, **which
makes it clear that it's binding `fs` to the named exports.** It saves the
reader from having to know that the module instance object is not the same
thing as the default export.
So there you have it... Feedback welcome, and as always we'll collect it all,
weigh it, and try to shepherd consensus.
Oh, and just to put parameters on the discussion:
* **I'm not proposing additional new import forms.**
If this syntax is future-compatible with other possible syntactic forms, that's
great, but that's not what we're discussing.
* **I'm not interested in discussing changes to the rest of the module syntax.**
This isn't the time or place to redesign the whole system.
* **The `this` binding in modules is a separate topic.**
The `this` binding in modules can be discussed independently of this topic.
tl;dr we're only talking about the ModuleImport syntax here.
Dave
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
