Modular application structure in Meteor.

Meteor.js - Interview Questions

Use in your application package.json file the section meteor.

This is available since Meteor 1.7

{
  "meteor": {
    "mainModule": {
      "client": "client/main.js",
      "server": "server/main.js"
    }
  }
}

When specified, these entry points will define in which files Meteor is going to start the evaluation process for each architecture (client and server).

This way Meteor is not going to eager load any other js files.

There is also an architecture for the legacy client, which is useful if you want to load polyfills or other code for old browsers before importing the main module for the modern client.

In addition to meteor.mainModule, the meteor section of package.json may also specify meteor.testModule to control which test modules are loaded by meteor test or meteor test --full-app:

{
  "meteor": {
    "mainModule": {
      "client": "client/main.js",
      "server": "server/main.js"
    },
    "testModule": "tests.js"
  }
}

If your client and server test files are different, you can expand the testModule configuration using the same syntax as mainModule:

{
  "meteor": {
    "mainModule": {
      "client": "client/main.js",
      "server": "server/main.js"
    },
    "testModule": {
      "client": "client/tests.js",
      "server": "server/tests.js"
    }
  }
}

The same test module will be loaded whether or not you use the --full-app option.

Any tests that need to detect --full-app should check Meteor.isAppTest.

The module(s) specified by meteor.testModule can import other test modules at runtime, so you can still distribute test files across your codebase; just make sure you import the ones you want to run.

To disable eager loading of modules on a given architecture, simply provide a mainModule value of false:

{
  "meteor": {
    "mainModule": {
      "client": false,
      "server": "server/main.js"
    }
  }
}