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?)
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)!
@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?
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
@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.