rauschma wrote: > > I think introducing new language constructs for modules is good, because > they are so fundamental. >
+1 rauschma wrote: > > For incrementally migrating old code bases, it would make a lot of sense > to allow ES.next modules to import AMDs and vice versa. > -1 I'm not sure if I understood this correctly, but trying to support backwards what was never a standard is probably not good idea, and AMD didn't get that much momentum to make exception for that, for many it's still controversial. rauschma wrote: > > Furthermore, npm’s ability to install modules locally and to let local > modules shadow global ones is a very smart way out of version hell. It > would be nice to have something similar for ES.next modules, but it’ll be > harder to do for browsers (as opposed to for Node.js and local file > access) > It belongs rather to packages concept not modules (at least in that way it originated from CommonJS). Currently I can't imagine any need for packages implementation in browsers. It's strictly just server-side and I assume it's fine to not have it standardized -- Mariusz Nowak twitter: http://twitter.com/medikoo github: https://github.com/medikoo ----- Mariusz Nowak https://github.com/medikoo -- View this message in context: http://old.nabble.com/Harmony-modules-feedback-tp33125975p33148342.html Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at Nabble.com. _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
