Meteor's folder conventions and loading order

Though Meteor doesn't impose restrictions concerning our folder names or structure, there are naming conventions that help Meteor's build process to determine the order in which the files need to be loaded.

The following table describes the folder and their specific loading order:

Folder name	Load behavior
client	This is loaded only on the client.
client/compatibility	This will not be wrapped in an anonymous function. This is made for libraries that declare top-level variables with var. Additionally, files in this folder will be loaded before other files on the client.
server	Files in this folder will only be served on the server.
public	This folder can contain assets used on the client, such as images, favicon.ico, or robots.txt. Folders and files inside the public folder are available on the client from root, /.
private	This folder can contain assets that will only be available on the server. These files are available through Assets API.
lib	Files and subfolders inside a lib folder will be loaded before other files, where lib folders in deeper folders will be loaded before the files in lib folders of their parent folders.
tests	Files inside this folder won't be touched or loaded by Meteor at all.
packages	When we want to use local packages, we can add them to this folder and Meteor will use those packages, even if one with the same name exists in Meteor's official package system. (However, we still have to add the packages using $ meteor add ....)

The following table describes filenames that have created a specific loading order:

Filename	Load behavior
main.*	Files with this name are loaded last, whereas files in deeper folders are loaded before the files of their parent folders
*.*	Files outside of the former mentioned folders in this table are loaded on both the client and server

So, we see that Meteor gathers all files except the ones inside public, private, and tests.

Additionally, files are always loaded in the alphabetical order, and files in subfolders are loaded before the ones in parent folders.

If we have files outside the client or server folder and want to determine where the code should be executed, we can use the following variables:

if(Meteor.isClient) {
  // Some code executed on the client
}

if(Meteor.isServer) {
  // Some code executed on the server. 
}

We also see that code inside a main.* file is loaded last. To make sure a specific code only loads when all files are loaded and the DOM on the client is ready, we can use the Meteor's startup() function:

Meteor.startup(function(){
  /*
  This code runs on the client when the DOM is ready,
  and on the server when the server process is finished starting.
  */
});

Loading assets on the server

To load files from inside the private folder on the server, we can use the Assets API as follows:

Assets.getText(assetPath, [asyncCallback]);
// or
Assets.getBinary(assetPath, [asyncCallback])

Here, assetPath is a file path relative to the private folder, for example, 'subfolder/data.txt'.

If we provide a callback function as the second parameter, the Assets() method will run asynchronously. So, we have two ways of retrieving the content of an assets file:

// Synchronously
var myData = Assets.getText('data.txt');

// Or asynchronously
Assets.getText('data.txt', function(error, result){
  // Do somthing with the result.
  // If the error parameter is not NULL, something went wrong
});

Note

If the first example returns an error, our current server code will fail. In the second example, our code will still work, as the error is contained in the error parameter.

Now that we understand Meteor's basic folder structure, let's take a brief look at the Meteor's command-line tool.