[meteor >= 1.3] proper way of importing core modules

help
1

Hi everyone,

Currently I am playing with the 1.3 (beta-12). In case of local, npm or atmosphere packages everything seems to make consistently sense - meteor add author:pkg (npm install pkg) and then import { default as foo } from 'meteor/author:pkg'; foo.bar(); But I am a bit confused about how to handle core packages. I did some testing and trial-and-error, and notice that core packages dont have to be installed in .meteor/packages or via api.use - an ES6 import simply gets the job done. I assume thats not recommended. Additionally this might not apply to all packages, at least the ones the build-tool depends on (ecmascript, modules, stylus, etc), but with e.g. check it seems to work. Then again, I am not sure if some core packages rely on the fact, that their dependencies are global. I think, it’s planed to evaluate post 1.3.

My question would be: what is the recommended (in terms of meteor >= v2, where things will break) way to tread core packages in the meantime?

My guess:

Proceeding as of Meteor <= v1.2, but instead of simply assuming the existence of all globals, just import everything thats needed, and one will be good, when the time has come, where every previously available global is gone.

If thats the case, it might be great to know how all the exports of the core package are look like or what are the schemas behind. (I am not sure, if everyone likes to lookup the package.js files – a temp. solution might be to include package.js information in docs.meteor.com)

2

I too would like MDG’s thoughts on this, and whether all globals can be eliminated somehow (which is good for security, because browser plugins can modify the window). Ideally we should use no globals, all code should run in a self-executing function, and the app developer should Object.freeze(window) in production (I haven’t seen any sideeffect of freezing window yet except that the Chrome console won’t work any more, but app code should be fine and secure).

((Imagine a browser plugin that overrides _.* methods if using a global version of underscore, then captures all sorts of sensitive data passed into those underscore methods, which is very easy to do.))

By freezing window, browser plugins and other 3rd party code would only be able to communicate with APIs that we may have put on window before freezing, just for that purpose, nice and securely.