Skip to content

Instantly share code, notes, and snippets.

@saurshaz
Created April 21, 2016 08:16
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save saurshaz/464fcb960c5469e9b271b7ffe5fbe3c6 to your computer and use it in GitHub Desktop.
Save saurshaz/464fcb960c5469e9b271b7ffe5fbe3c6 to your computer and use it in GitHub Desktop.

A directory structure i use for Node projects

  1. rootproject folder (starting point) 2. project_name folder 3. package.json file 4. node_modules folder (all dependencies) 4. .env file (or/and other non-committed environment/settings files) 5. project_name folder (the folder to contain source code) 6. appfolder (client side files) 7. server folder (server side files) 8. lib folder 9. environment.js file (to load up .env file from outside - outer project_name folder) 10. logger.js file (the logger for the app - i use bunyan here) 11. middleware file (all commonly shared middleware can live as functions (i use express, applicable even for hapi) 12. index.js the file that starts the server app 13. public folder (all static stuff) 14. views templates. I use nunjucks 15. package.json file (linked to the other package.json file from outer project_name folder,. changes made in either shall be reflected in the other one. u can use symlink(ln -s) or any other means for that)

(heavy influence of Mozilla projects for structure and tools. I loveeee Mozilla FOSS )

###What do i see better in this structure

  • I can do everything i need , or everything i do in normal project structure and more

  • I just need to type extra to start the server :-( small downside

  • My simple command is LOG_LEVEL=info nodemon -w applyx/applyx/ ./applyx/applyx/server.js (notice how i instructed nodemon to only watch selected directories for restarting server)

  • I work on multiple projects my directory structure allows me to start the server from rootproject dir in terminal always. i start my system terminal in same dir always. no more cd for switching to a different project. some productivity boost i feel

  • I can debug any project starting node-inspector from the same location always. just restarting that particular project in debug mode --debug

  • I feel keeping node_modules in a different directory brings to me a unique way to share the code synced to my VPS. I only now share the project_name/project_name/** contents to be synced over bittorrent sync/dropbox for syncing to my VPS. this was a big plus. i know i can always use git but if i want realtime sync from my dev machine to VPS then this has been a big help for me (avoiding multiple steps)

  • not ideal (as dependencies get mixed up) but you may think of using a common node_modules for different projects inside root_project for different projects, hence can avoid too much npm install (other option , which is better but overhead-inclusive is to have sinopiaor npmc usage to install stuff(use the cache))

I am sharing this to invite feedback and suggestions on what is missing in this structure, and where this might fail. Also suggestions on what can be improved in this.

Also I feel these are the things which are a must for me as a web developer (in a project codebase)

- client side debugability (i will avoid ES6 code without source-maps)
- server side debugability (i will avoid ES6 code without source-maps. bode-inspector has not been as great as node-inspector for me). I will wait to write ES6 in an app until ioJS gets it in. It's not that long i hear
- logging on-demand easily configurabile on both sides(client n server) (i strongly recommend `bunyan` and `bole`)
- environment variables (i strongly recommend `habitat` and `bole`)
- testability at all ends, if all tests are there, i would probably learn more from tests and codebase than from the documentation, which oudates itself rapidly in an evolving project. And incorrect documentation is like a false warranty(makes matters worse) 
- lastly (not least) simplicity of a codebase which might be doing a very complex thing
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment