What is the recommended folder structure for Meteor 1.3?

Showcase
9

I blame my brother, he hates curly braces and he’s making things pop on the UI/UX side. :stuck_out_tongue:

1 Like
10

Stylus is even better!

2 Likes
11

I’ll say it: I love brackets…

5 Likes
12

LMAO. And you guys need a chat room :wink:

1 Like
13

I am very very excited to see this @sergiotapia!

14
1 Like
15

heloo, @sergiotapia what is archives folder…?? is that to store the depreciated code but maybe you need someday…?? if that so, how you manage to prevent meteor to load file inside archives folder…??

thank You,

16

Hi @karina “archives” is just a bad translation of “archivos” to English. It’s just a simple view meant to draw a list of all the files the user has uploaded.

17

ohhh i see, i have a lot of depreciated code but don’t know where to store, uncommenting looks dirty…

18

You should use version control for this! Create a branch with the old code for later. Alternatively, you can put it in the private directory of your app.

Also, in Meteor 1.3 files aren’t going to be loaded by default in the imports directory, so it will be possible to have unused files, although I wouldn’t recommend it.

2 Likes
19

I’ve been experimenting with a folder structure like this:

295×640 6.96 KB

I’m currently developing a CLI tool that does all this scaffolding for you, but I’m still working on what the best scaffolding would be.

3 Likes
20

@idmontie Even better! We are in dire need of a good scaffolding tool for React + Meteor modules

1 Like
21

I will make a post on these forums most likely this weekend announcing the project and asking for feedback. Hopefully it’s a hit :wink:

1 Like
22

ahhh, right version control, i forgot and don’t really understand about that

thank You for mentioning private directory, as long as i never call assets api, they never load… this is the most easiest way for short term project i think,

23

I’ve used a slightly different structure for each app and for Meteor apps… if you like the isomorphic approach you would be to do something like this (my app using this is using webpack but the same concept.

Note this is very flat and is not nested in a server or client folder. If you need it you just require it regardless of where you are. If the code has different implementations then you can use a client/server filename and import that like: import 'models/posts-server and import 'model/posts-client'.

However, it’s unclear how entry points will be handled so /main.server.js may need to be in /server/main.js if they are loaded implicitly:


styles/
  _typography.scss
  main.scss
publications/
   post.js
subscriptions/
   post.js
utils/
   foo.js
models/
  post.js
domain/
  post.js
  post-spec.js
  user.js
  user-spec.js
pages/
  _feed.scss
  feed.html
  feed.js
tests/
  fixtures/
  spec-helper.js
components/
  post/
     _posts.scss
     post-item.js
     post-item.html
     post-list.html
     post-list.js
main.client.js
main.server.js
25

Did you not see this post?

1 Like
26

After experimenting a lot, I came to the conclusing that the best way to structure Meteor is to not use folders on the app level at all :slight_smile: . Instead, I am putting nearly everything into packages. This feels a bit more complicated at first sight, but the benefits outweigh the additional work. You get a much more modular app, and you always know exactly how things depend on each other. Especially if you want to re-use code across apps, this is a big plus. I still have some global folders, but they mainly contain central UI components I am using across the whole app (and I did not move them to their own packages yet because they were developed at a time when I did not follow the “package first” approach).

1 Like
27

Any chance you can show us an example? I’m still on the fence about this myself… thanks.

28

Sure.

259×1033 25.6 KB

301×1074 25.2 KB

Some explanations:

  • .deployment contains everything I need to deploy my app to EC2, using mupx
  • .settings is just an Eclipse folder (I’m using Eclipse as an SVN client), so please ignore it.
  • client is mainly used for SCSS stylesheets and templates that are app-specific. Some of these files are also candidates for packages, since I use them a lot and created them before I went the package-first approach. The client/mobile folder contains global code that is used on mobile devices only. In fact, it only contains 1 file that sets up an interface between Cordova and my app.
  • config is for code that is used to configure central services like useraccounts. These files are only necessary if the service cannot be configured by using settings.json alone.
  • lib contains global i18n files (e.g. for button texts) and global routes (e.g. for “404 not found”).
  • packages is where most parts of my apps live. After experimenting a bit, I came to an approach where I split up function modules in 2 packages: one for model classes, collections, methods and other business logic, and one for the UI (with postfix “-ui”). This helps to avoid circular package dependencies, which would otherwise occur because UI templates tend to use several model packages.
  • private is mainly used for images that should not be published on the web (mobile icons and splashscreens), and it also contains my credential files for the Apple push notification service (APNS).
  • public contains fonts and images to be delivered online.
  • tests will contain testing code. But since I never managed to setup Velocity in a satisfying way, it is mostly empty at the moment (I’m hoping for Meteor 1.3).

HTH, Tom

1 Like
29

Great example, thanks!