The top-level directory structure contains:
app/ # holds the Meteor application sources config/ # holds configuration files, such as settings.development.json .gitignore # don't commit IntelliJ project files, node_modules, and settings.production.json
This structure separates configuration files (such as the settings files) in the config/ directory from the actual Meteor application in the app/ directory.
The app/ directory has this top-level structure:
client/ lib/ # holds Semantic UI files. head.html # the <head> main.js # import all the client-side html and js files. imports/ api/ # Define collection processing code (client + server side) base/ interest/ profile/ startup/ # Define code to run when system starts up (client-only, server-only) client/ server/ ui/ components/ # templates that appear inside a page template. layouts/ # Layouts contain common elements to all pages (i.e. menubar and footer) pages/ # Pages are navigated to by FlowRouter routes. stylesheets/ # CSS customizations, if any. node_modules/ # managed by Meteor private/ database/ # holds the JSON file used to initialize the database on startup. public/ images/ # holds static images for landing page and predefined sample users. server/ main.js # import all the server-side js files.
This system adheres to the Meteor 1.4 guideline of putting all application code in the imports/ directory, and using client/main.js and server/main.js to import the code appropriate for the client and server in an appropriate order.
Then, client/main.js and server/main.js are responsible for importing all the directories containing code they need. For example, here is the contents of client/main.js:
import '/imports/startup/client'; import '/imports/ui/components/form-controls'; import '/imports/ui/components/directory'; import '/imports/ui/components/user'; import '/imports/ui/components/landing'; import '/imports/ui/layouts/directory'; import '/imports/ui/layouts/landing'; import '/imports/ui/layouts/shared'; import '/imports/ui/layouts/user'; import '/imports/ui/pages/directory'; import '/imports/ui/pages/filter'; import '/imports/ui/pages/landing'; import '/imports/ui/pages/user'; import '/imports/api/base'; import '/imports/api/profile'; import '/imports/api/interest'; import '/imports/ui/stylesheets/style.css';
Apart from the last line that imports style.css directly, the other lines all invoke the index.js file in the specified directory.
We use this approach to make it more simple to understand what code is loaded and in what order, and to simplify debugging when some code or templates do not appear to be loaded. In our approach, there are only two places to look for top-level imports: the main.js files in client/ and server/, and the index.js files in import subdirectories.
Note that this two-level import structure ensures that all code and templates are loaded, but does not ensure that the symbols needed in a given file are accessible. So, for example, a symbol bound to a collection still needs to be imported into any file that references it.
This system adopts the following naming conventions:
- Files and directories are named in all lowercase, with words separated by hyphens. Example: accounts-config.js
- Templates representing pages are capitalized, with words separated by underscores. Example: Directory_Page. The files for this template are lower case, with hyphens rather than underscore. Example: directory-page.html, directory-page.js.
- Routes to pages are named the same as their corresponding page. Example: Directory_Page.