Isn’t the problem, though, that default-exporting an object prevents static checking? It feels like an abuse of this feature to me.
With a ModuleImport statement, you have the choice between selectively importing items and importing everything as an object. With default-exporting an object, you don’t have that choice (you can work around this limitation, but still). I do see your point, but I think module imports are useful when the contents of a module change relatively frequently and/or if there are many items in a module. In other words, I think that is something that will live on (justifiedly so) and should be supported properly. On Jun 9, 2014, at 8:49 , Domenic Denicola <[email protected]> wrote: > I am beginning to come around to the removal. It will just encourage module > authors to use default exports exclusively (e.g. fs will default-export an > object including readFile et al., instead of exporting multiple functions), > which will put us squarely back in parity with the CommonJS/AMD systems, and > ease migration. > > If module authors try to use multi-exports, they will get upset users who > wish to be able to do `import _ from "underscore"; _.zip(…)`, but cannot. So > instead they will use default exports only, which does allow this familiar > style. > > In the end all of the non-default export forms, and the braced multi-import > form, will just be relegated to the “bad parts” bin, and default exports and > unbraced single-import will remain in the “good parts” bin, giving us the > same CommonJS/AMD world we have today, but with some vestigial syntax unused > by popular libraries. > > From: es-discuss [mailto:[email protected]] On Behalf Of Axel > Rauschmayer > Sent: Monday, June 9, 2014 02:39 > To: es-discuss list > Subject: Rationale for dropping ModuleImport syntax? > > Context: > https://gist.github.com/caridy/eefb9b104874465d4e1c#1-moduleimport-syntax-importdeclaration > > ```js > module foo from "foo"; // drop this > import bar from "bar"; > ``` > > I’m seeing the following contra against dropping ModuleImport syntax: > > > Contra: without a way to access the module object, it is difficult to deal > > with modules with many exports (e.g.: underscore), but we could fix this by > > using a reflective API to access imported modules > > Isn’t this a frequent use case? Which would lead to ugly and very > inconsistent code, especially if multiple imports are involved. I also don’t > see how CommonJS-style modules could be neatly migrated to ES6 modules if > this feature was dropped. > > I do agree that the ModuleImport reads a bit strange, but that could be > fixed, e.g. via a suggestion I’ve seen somewhere: > > ```js > import module foo from "foo"; > ``` > > -- > Dr. Axel Rauschmayer > [email protected] > rauschma.de -- Dr. Axel Rauschmayer [email protected] rauschma.de
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
