From: es-discuss <[email protected]> on behalf of James Burke
<[email protected]>
> 1) Only allow export default or named exports, not both.
As a modification of the current design, this hurts use cases like
```js
import glob, { sync as syncGlob } from "glob";
import _, { zip } from "underscore";
```
> 2) Only allow `export` of one thing from a module, and `import {}` just means
> allowing getting the first property on that export. This removes the named
> export checking, but that benefit was always a bit weak, even weaker with the
> favoring of default export.
I definitely believe that if the community were designing a syntax-based module
format, incorporating the lessons learned so far, it would end up being along
these lines. We've learned enough from browserify and RequireJS's
CommonJS-wrapping to know that a top-level static import form has serious
benefits, but we've also learned that `module.exports =` or `return` are the
recommended and primary pattern, and you can always attach things to that
"default export" as properties if necessary. (In CommonJS terms, we've learned
that the benefits of typing `exports.x = y` instead of `module.exports.x = y`
are not great enough to outweigh the minor confusion of having two export
forms.)
Unfortunately, that's not the world we live in, and instead TC39 is designing a
module system based on their own priorities. (Static checking of multi-export
names, mutable bindings, etc.)
They've (wisely) decided to add affordances for the community's use cases, such
as layering default exports on top of the multi-export model. As well as Dave's
proposal in this thread to de-grossify usage of modules like "fs". By doing so,
they increase their chances of the module system being "good enough" for the
community, so that the path of least resistance will be to adopt it, despite it
not being designed for them primarily. It's still an open question whether this
will be enough to win over the community from their existing tools, but with
Dave's suggestion I think it has a better-than-even chance.
The transitional era will be a particularly vulnerable time for TC39's module
design, however: as long as people are using transpilers, there's an
opportunity for a particularly well-crafted, documented, and supported
transpiler to give alternate semantics grounded in the community's preferred
model, and win over enough of an audience to bleed the life out of TC39's
modules. We already see signs of community interest in such "ES6+" transpilers,
as Angular illustrates. Even a transpiler that maintains a subset of ES6 syntax
would work: if it supported only `export default x`, and then gave `import { x
} from "y"` destructuring semantics instead of named-binding-import semantics,
that would do the trick. Interesting times.
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
