ModuleImport

[Russell Leggett]

>
>
> Ok, so can I just ask a serious question. I looked at the mkdirp library,
> and in their own documentation, they use:
>
>     var mkdirp = require('mkdirp');
> So let's say in the new world order, no default exports, this is a named
> export mkdirp. Is it *really* that bad a thing to just use the name they
> chose for their API? I mean what about all of the likely cases of exporting
> a class. Would you advocate for those classes to be aliased before use?
> What about methods? Those are typically unchanged. The argument has been
> made that without default exports, library users would then have to known
> the name of the exported member. Is that really a serious complaint? You
> *have* to know what everything else is called, what parameters are
> expected, etc. I would go as far as to say that either 1 of 2 things is
> happening.
>
>
>
Ok, accidentally sent...  either 1 of 2 things is happening....

1) The imported function is always called the same thing when imported. Its
a de facto standard.
2) There is no de facto standard, and people call it a variety of things.

I would argue that 1 is easy to transition, just export with that name, and
2 is not really a good thing. Its much harder to read or grep your code. It
is an anti-pattern that should not be given so much sugar. Aliasing is
still possible, but more awkward.

I know Kevin and I both said this, but IMO the reason this pattern became
so popular was to avoid:

    var mkdirp = require("mkdirp").mkdirp;

In my proposal (no curlies), that's simply:

    import mkdirp from "mkdirp";

The big thing missing is just ease of aliasing, and I don't really see that
as a problem. I'd love to hear an argument for why I'm wrong.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140627/10446142/attachment-0001.html>