d at domenic.me (2015-03-03T21:08:59.167Z)
I think you misunderstood my comment about
import * from ‘./foo’
I am aware of
import * as foo from ‘./foo’
and that is fine. My former example is the desire to have `foo`’s exports injected as-is into the module’s scope (bar vs foo.bar, etc.). There are times where this is desirable, wherein enumerating { bar1, bar2, bar3, barN... } is just a waste of time and maintenance headache.
As for refactoring hazards I can appreciate that JavaScript has a lot more to protect against than strongly typed languages. Refactoring in JavaScript is generally unsafe for any number of reasons.
Hi Caridy, I think you misunderstood my comment about import * from ‘./foo’ I am aware of import * as foo from ‘./foo’ and that is fine. My former example is the desire to have `foo`’s exports injected as-is into the module’s scope (bar vs foo.bar, etc.). There are times where this is desirable, wherein enumerating { bar1, bar2, bar3, barN... } is just a waste of time and maintenance headache. As for refactoring hazards I can appreciate that JavaScript has a lot more to protect against than strongly typed languages. Refactoring in JavaScript is generally unsafe for any number of reasons. Jason > On Feb 19, 2015, at 7:55 PM, caridy <caridy at gmail.com> wrote: > > inline > >> On Feb 19, 2015, at 7:50 PM, Jason Kuhrt <jasonkuhrt at me.com> wrote: >> >> Hey Matthew, >> >> This is another pattern I could take yup. >> >> Kevin pointed that if I suck it up and move all my modules toward named-exports then my problems go away too. The reason I am using default internally was that I had modules depending on others which are all uniformly single-function modules (react components to be specific). So it felt confusing to have this syntax internally: >> >> import { foo } from ‘../foo’ >> >> When what I’m really trying to express is: >> >> import foo from ‘../foo’ >> >> But ultimately if I am willing to accept that internally I use the former syntax then my re-export expressions are fine: >> >> export * from ‘./foo’ > > In my mind, this is good for proxy modules, shims, and other edge cases, but keep in mind that excessive usage of this (e.g.: multiple export *… in the same module) can become a refactor hazard. > >> These are small details but added up they matter. Generally I’m happy with modules though. The only other gripe I have is not being able to import each export naked into a namespace like this: >> >> import * from ‘./foo’ > > that’s exactly what `import * as foo from “./foo”` does it :) > > /caridy -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150219/53cb3e75/attachment-0001.html>