My (general) new node project directory structure

project-structure.md

Project structure

Example project directory, the root folders are pretty consistent, the sub directories (on lib, etc) are just examples of what might be in there.

.
├── lib
│   ├── db
│   ├── handlers
│   └── routes
├── node_modules
├── public
│   ├── assets
│   ├── css
│   ├── images
│   └── js
├── tests
└── views
    └── _partials

• . root – config files: .jshintrc, .gitignore, Procfile, package.json, README.md, etc
• lib – server side application code root (often includes subdirectories)
• node_modules – dependencies
• public – public facing client code: .html files, directories: js, css, images, fonts, etc
• views - server side templates
• tests - test directories that mirror lib with (ideally) <script>.test.js mirrored filename

Potential extras

• bin – if there's CLI tools included
• docs – though if you're able to put this in a wiki, it might make more sense
• coverage – output of test coverage (this would be nice in all projects)

LGTM 👍 although move templating client-side

How do you manage configuration stuff?

Similar. Where will you accommodate the front-end specific unit tests? Will that be under tests folder again?

@shapeshed jsbin is the more complicated example of configs.

We have a config.default.json which holds the minimum that we need to run the app - default ports, db config, etc.

Then a config.js module in lib will load the default, and then try to override values from config.local.dev, and then finally environment values override all.

If it's a simple project, I'll just have a config.json and env values override (such as hosting on heroku).

@sreekarun I'm very weak at tests, and it's only recent projects that include them by default, so front-end tests are missing because I'm not writing them. Where do you keep them typically?

Client side only projects have started looking like this:

.
├── dist
├── src
└── tests

Though that's just a library like min.js - and I rather like Karma for testing client stuff, though I'm sure that will change over time.

What templating engine do you prefer, Remy?

@abitgone handlebars - and I definitely want to check out HTML Bars

I should note - this (my structure) doesn't address MVC at all. Unsure whether that's a bad thing or not.

I'm a newbie, but I stick with this, kind of what I've been using with PHP.

.
├── config
├── controllers
├── lib
│   ├── [a file]
│   └── [a different one]
├── middlewares
├── models
├── node_modules
├── public
│   ├── assets
│   ├── css
│   ├── images
│   └── js
├── routes
├── tests
└── views
│   ├── global (this represent what you probably put on _partials)
│   └── [section_name]

I just want ask you, do you keep your front-end and backend under the same directory like this structure:

├── client
├── server
└── shared

I saw this same structure on Ghost

There's also this (similar to @wellingguzman) which includes MVC-ish (I've avoided "controller" and used the word "routes" - because that's what they are):

.
├── lib
├── models
├── public
│   ├── css
│   ├── fonts
│   ├── images
│   └── js
├── routes
├── tests
└── views

That also said, I don't personally use Sass and the like, so I don't really know where pre-processed files would go.

Pretty much the same as me. But i call public assets and images are gfx (early y2k thing I think?)

Having run through a few drafts of boilerplate myself, I found Sail.js pretty comforting (even if I turn off many of the features). I also kind of liked some of the structure from LoopBack. Not a sales pitch but I have been trying to look at larger frameworks for inspiration vs slowly evolving on my own. I typically add convention & abstraction little by little (e.g. adding separate config space for DBs, etc); I feel like I keep getting asymptotically closer to reinventing the wheel.