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.
All code in the client directory is run only in the client-side, or web browser.
The compatibility directory contains legacy or 3rd party code, such as jQuery libraries, etc.
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.
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.
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.
The private directory contains static files that should only be available on the web server.
The public directory contains static files that are only available on the application client. This may including branding assets, etc.
The server directory contains server-side assets. This can include authentication logic, methods, and other code that may need security consideration.
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.