Api.mainModule or api.addFile?

help
1

Does a file added with api.mainModule get automatically executed similarly to main modules in the app? Suppose we want to make a package that has stuff exported from various files a.js, b.js, and c.js. Can we skip using api.mainModule and just import directly from those files? For example:

// package.js
Package.describe({
  name: "my-package"
});

Package.onUse(function (api) {
  api.use(["modules", "ecmascript"])
  // assume the package has a.js, b.js, c.js, but we skip
  // the use of api.addFiles and api.mainModule.
});

// app code:
import A from 'meteor/my-package/a'
import B from 'meteor/my-package/b'
import C from 'meteor/my-package/c'

console.log(A, B, C)

Is this sort of module usage okay, or would this be not recommended?

(This works when the package is local to the app’s packages folder, but does the lack of api.addFiles or api.mainModule mean that files will be missing if we publish the package to Atmosphere?)

2

I guess it doesn’t matter after all! We’ve plan to move our packages to a private NPM registry. Hooray for Meteor 1.3+ (and sinopia)!

3

@benjamn Would you kindly share some insights here? Also, is api.mainModule compatible with older versions of Meteor? For example, is the following valid?

Package.onUse(function (api) {
  api.versionsFrom(['METEOR@0.9.0', 'METEOR@1.0', 'METEOR@1.2', 'METEOR@1.3']);
  api.mainModule('main.js'); // main.js exports things.
});

I am assuming mainModule exports the module’s export in a manner similar to api.export for the older packages. Is that right?

4

Unfortunately, api.mainModule is not compatible with versions of Meteor before 1.3. More importantly the modules package is not compatible with earlier versions of Meteor, and api.mainModule doesn’t make much sense without modules.

If you want to continue publishing a package for Meteor 1.2.1 and earlier, the package should not use modules, should avoid calling api.mainModule, and should probably be published using meteor publish --release 1.2.1 or similar.

Though upgrading an app to Meteor 1.3 should be relatively painless, publishing Meteor 1.3-style packages for older versions of Meteor isn’t really possible, given the changes that happened to the Meteor command-line tool between 1.2.1 and 1.3.

1 Like
5

@benjamn It als seems like api.mainModule automatically makes globals out of the main module’s exports (is the package is a direct dependency of the app). Isn’t this what we’re trying to avoid?

As workaround, api.addFiles without api.export (i think) prevents globals.