Explicit imports/exports
mquandalle opened this issue · 7 comments
The whole JavaScript ecosystem, on both client and server side, converge to a model in which we can export an API from a given file and import it elsewhere. The semantic of the operation varies, but this will probably be fixed with the upcoming EcmaScript 6 standard. On the other hand, Meteor sharing model relies on globals. The linker rewrite last year improved things by automatically wrapping files in closures so only variables without the var keyword are now “exported” (and this rewrite also improved the situation of packages). But there is still room for improvements in this area, and I think a reasonable solution would be to follow the ES6 standard.
I was thinking the same.
That sounds like it's moving back towards static linking and import and require statements (ick). Hopefully that's not what you're suggesting.
👎 import and require can be useful for lower level programming, though I hold my doubts, but I feel it does not belong at the app level. Packages provide the proper level of name-spacing and with closures as the app default their is no risk of global pollution.
at a package or library level it would be nice to have really finegrained dependencies (like famono) - but on app level I think it's fine as is.
The problem with the current model is that you cant export globals as new global name in case of collisions - that said its easy enough to access package scopes via Package['foo:bar']
Packages are a more reasonable place for import/require ^_^ I can't say I would be happy to see it unless we get some massive memory optimization as a result.
I could see renaming package globals as a possible package configuration #58. I feel like conflict is the exception and should be handled as such.
True, memory isnt a problem yet - I'm prop. old school but I really like the finegrained imports / only including whats actually needed - not sure if it has any real impact on memory / code optimization in VM
But from a reusability point of view I think we need to differentiate between packages and libraries - eg. when I'm writing packages is bugging me that I cant access / reuse parts/functions in core/other packages - so I have to add and maintain my own version... This is a general problem i the js world, just now we have chance to fix it.
import/export is in the work and will be released as part of Meteor 1.3.