I know how to write Meteor packages but I can\'t seem to figure out how to have all exports land in my app\'s namespace, as described in this presentation.
This particul
All properties that you register in your app namespace are made available for the packages that depend on (use) your app-package. So, when you want to register a package namespace in an app-namespace, you declare the dependency on the app-package within your package and you register all of the methods/objects you want to export in the app-namespace. An example:
file: packages/myapp/namespace.js
MyApp = {};
file: packages/myapp/package.js
Package.on_use(function (api, where) {
api.add_files([
"namespace.js"
], ['client', 'server']);
api.export("MyApp", ['client', 'server']);
});
file: packages/myapp-module1/logic.js
packageSpecificMethod = function(){}
moduleOne = {};
//you can export an module-specific namespace by registering it in the app-namespace
MyApp.module1 = moduleOne;
//or you can (if you dont want package-namespaces) register you private methods in the app-namespace directly
MyApp.exportedMethod = packageSpecificMethod;
file: packages/myapp-module1/package.js
Package.on_use(function (api, where) {
api.use([
'myapp'
], ['client', 'server']);
api.add_files([
"logic.js"
], ['client', 'server']);
});
In your package, you should define all methods and symbols in the namespace you want them to have, and then export that namespace. So, if in your package you've got:
MyApp = {
myMethod: ...
};
Then you export it with api.export('MyApp')
.
Unfortunately, there's no method similar to the one in Node you've mentioned, as all packages are loaded globally on startup.
The api.export
method is only supported for top-level variables right now. It doesn't work for nested variables, because "it turned out that using deep exports was
very confusing", and what would you expect MyApp.myMethod
to appear as in the global namespace if you also exported MyApp.myOtherMethod
?
You should just export MyPackage
, and then call MyPackage.myMethod()
. A common approach is to do something like
MyPackage = {
myMethod: someSecretMethodName,
myOtherMethod: otherMethodName
}
And then call api.export("MyPackage")
. This means that the exported names of variables don't necessarily have to be what you called them. This is used a lot in the core meteor packages; you can also see an example at for MongoInternals in mongo_driver.js.