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)