>> Isn't the problem, though, that default-exporting an object prevents static >> checking? It feels like an abuse of this feature to me. > > We don't have static checking today, so this is no loss to me.
If I understand ES6 modules correctly, importing a non-exported identifier gives you a load-time error (that’s what I meant with “static checking”). If you default-import an object with exports, you only get run-time errors. This is more subjective, but what I like about modules is that they lead us away from objects-as-modules. If default exports, used in this manner, become popular, that won’t really happen. We’ll have pseudo-modules, used inside a module system. > (And ES6 modules give enough benefits over ES5 ones without static checking > to still have a chance in the marketplace, e.g. they statically require > imports being at top-level and string-only, and automatically introduce `"use > strict"` for you.) I agree. I also love tools such as the es6-module-transpiler, which allow us to move beyond the AMD/CJS schism right now. -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
