大型应用时，meteor推荐的文件结构

[魏永清]

推荐的文件的结构：链接

The example apps in meteor are very simple, and don’t provide much insight. Here’s my current thinking on the best way to do it: (any suggestions/improvements are very welcome!)

lib/                    # <- any common code for client/server. 
lib/environment.js      # <- general configuration
lib/vendor              # <- common code from someone else
## Note that js files in lib folders are loaded before other js files.

models/                 # <- definitions of collections and methods on them (could be collections/)

client/index.html       # <- toplevel html
client/index.js         # <- and it's JS
client/application.js   # <- subscriptions, basic Meteor.startup code.
client/environment.js   # <- configuration of any client side packages
client/views/page.html  # <- the templates specific to a single page
client/views/page.js    # <- and the JS to hook it up
client/helpers          # <- any helpers (handlebars or otherwise) that are used often in view files

server/publications.js  # <- Meteor.publish definitions
server/methods.js       # <- Meteor.method definitions
server.environment.js   # <- configuration of server side packages

For larger applications, discrete functionality can be broken up into sub-directories which are themselves organized using the same pattern. The idea here is that eventually module of functionality could be factored out into a separate smart package, and ideally, shared around.

feature-foo/            # <- all functionality related to feature 'foo'
feature-foo/lib/        # <- common code
feature-foo/models/     # <- model definitions
feature-foo/client/     # <- files only sent to the client
feature-foo/server/     # <- files only available on the server