ModuleImport

Jussi Kalliokoski jussi.kalliokoski at gmail.com
Thu Jul 3 02:31:12 PDT 2014


On Thu, Jul 3, 2014 at 11:41 AM, Brian Di Palma <offler at gmail.com> wrote:

> > So sometimes someone can need it, so we must have good support? Is that
> how we operate these days?
>
> Imagine a large codebase which already has transitive cyclic dependencies.
> If the module system has poor support for them it might still work
> with them until one day a developer reordered the import statements.
> How would you feel if such a simple operation caused you issues?
>

Happy; finally having a good motivator to refactor and get rid of the
cyclic dependencies, at least in that compartment.


> Or upgrading to the latest version of a popular utility toolchain like
> lo-dash could introduce an issue purely because the upgrade created a
> transitive cyclic dependency.
> And the fix for that would be to reorder your import statements and
> add comments in your module telling people not to change the order.
> Again, how would you feel?
>

Angry at lo-dash for breaking backwards compatibility, then I'd revert the
upgrade and file a bug against it. I'd probably also consider whether
lo-dash were in this imaginary case something I want to depend on given
that for a utility library they need cyclic dependencies. I'd also be happy
that the module system made this obvious.

But I get your point since I'm well aware that my thoughts are likely not
to be a very good representation of how most people would feel.

However, I still don't think it's something worth making other sacrifices
over.


> Default import and exports are purely sugar over
>
> ```
> import {default as MyClass} from 'MyClass';
> ```
>
> It saves you a few character typing out when importing from legacy
> module system.
>
> ```
> import MyClass from 'MyClass';
> ```
>
> Those two are the same thing.
>

Ughh, I see. Not cool.


> From birth the brand new module system is going to have this
> superfluous appendage to support


Let's not have it. At least not in ES6. Tools like Traceur can support it
for an easier migration path since they already have diverged from ES.next
anyway with all the annotations (for which, off topic, I haven't seen even
a proposal here yet) and stuff.


> module systems that 10 years from now
> people will struggle to remember.
>

I certainly hope that will be the case, but it's 2014 and people are still
implementing banking with Cobol, security protocols with C++ and website
cryptography with Java applets.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140703/6f6900e3/attachment.html>


More information about the es-discuss mailing list