Before the release of Meteor 1.3, Meteor developers were frustrated with Meteor.js' handling of file dependencies and global variables. In response, Meteor set new standards for project structures in order to make the project dependency system more streamlined. This topic explains the standardized project structure and the principles behind it.
client
All code in the client directory is run only in the client-side, or web browser.
client/compatibility
The compatibility directory contains legacy or 3rd party code, such as jQuery libraries, etc.
lib
The lib directory is loaded before other directories in your Meteor project, and is loaded on both the server and client. This is the preferred place to define data models, isomorphic libraries, and business logic.
imports
The imports directory is a directory on the server that is available to both the server and client, but only before the client bundle gets shipped to the client.
packages
The packages directory is where custom packages are stored during local development. When using the standard command meteor add package:name
to add a package, Meteor will look first in this directory if a local package has the corresponding description name in its package.js
file. If not, it will poll Atmosphere as usual.
private
The private directory contains static files that should only be available on the web server.
public
The public directory contains static files that are only available on the application client. This may including branding assets, etc.
server
The server directory contains server-side assets. This can include authentication logic, methods, and other code that may need security consideration.
tests
The tests directory is omitted by default when your application is bundled and deployed.
As suggested by Richard Silverton it is a convenient idea to put not only the meteor project directory under version control, but also its parent directory.
That way you can keep files under version control without having meteor to deal with it.