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 particular package is specific to an app I'm building, and it exports only one method that can be regarded as a decorator on the app's singleton. I tried api.export('MyApp.myMethod') but that gives an error native: Bad exported symbol: MyApp.myMethod.

If I just api.export('myMethod'), then in the app code I have to call myMethod(), and that's not namespaced.

Does Meteor have a mechanism similar to Node's var http = require('http');? Or how can packages export symbols into a given namespace?

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 particular package is specific to an app I'm building, and it exports only one method that can be regarded as a decorator on the app's singleton. I tried api.export('MyApp.myMethod') but that gives an error native: Bad exported symbol: MyApp.myMethod.

If I just api.export('myMethod'), then in the app code I have to call myMethod(), and that's not namespaced.

Does Meteor have a mechanism similar to Node's var http = require('http');? Or how can packages export symbols into a given namespace?

• javascript
• meteor
• javascript-namespaces
• global-namespace
• namespace-organisation

3 Answers 3

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.

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.