Development - VITCMUN/munverse GitHub Wiki

Project Structure

Here's an outlook of the project:

munverse/
├── .circleci/
├── controllers/
├── db/
│   └── docker-entrypoint-initdb.d/
├── middlewares/
├── media/
├── models/
├── public/
├── renderer/
├── routes/
├── scripts/
├── test/
│   ├── api/
│   │   ├── admin/
│   │   ├── auth/
│   │   ├── message/
│   └── unit/
├── utils/
├── views/ 
|   └── partials/
├── config.js 
├── app.js

Each directory serves a unique purpose. They follow the general MVC convention. The test directory is bifurcated into api and unit. The former holds all the tests which tests endpoints, as a result of which the server needs to be started (this is managed by the testing script only). The latter contains unit testing of functionalities which can be done offline. views contain all the ejs templates and partials contain the reusable parts of the templates. media contains image assets and is in .gitignore.

File Naming Convention

All file names should be in small letters with snake_casing and should encapsulate the path details. Note that, if the directory name is a plural word, the filename should contain the singular version of it. For example, all files in the routes directories will be named as *.route.js; like auth.route.js. Directories won't follow this convention and will be named normally. However, file names within subdirectories will follow a naming hierarchy.

For example,

src/
├── folder_one/
│   ├── file_one.folder_one.js
│   ├── folder_two/
│   |   ├── file_two.folder_two.folder_one.js

Test Driven Development

This project follows the TDD approach; that means test cases are written first and then functionality is coded so that you pass all the tests. Before pushing any code, make sure to run the tests locally once. We use CircleCI to test all your code again once you make a pull request!

All test cases must be written in Mocha/Chai. Don't forget to include process.env.NODE_ENV = 'test' at the beginning of every test file. It enforces the test environment and takes care of a few things that needs to be taken care of for this particular environment.

CircleCI configuration can be found in config.yml under .circleci directory.

Logger

Logging is an important functionality for tracking bugs and errors across the system. We are using the Winston logger for maintaining two streams of logs - STDOUT and an error file. The error file's path can be changed from the config file.

Developers need to mandatorily log events while programming the system. All errors must be logged using logger.eror and all informational events must be logged using logger.info.

• Example of an error - say some function fails to execute. Ideally, all .catch(error) must be logged as error.
• Example of an info - say some user logs in, so that is an information.

The logger utility is located at /utils/logger.js. Sample code snippet:

// include
const logger = require('./utils/logger')
// log
logger.info('This is an informational log')
logger.error('Error reported')

Making a PR

Fork this repository first and then make local changes. Test that change and push it to your own repo. Create a pull request now.

Whenever you make a pull request, it is moved into a Docker image and the test cases are run. Then, a member of our team reviews your code and decides if it is eligible for merging. You will get change requests if certain things don't look good. A PR with no message will be rejected straightaway. If everything passes, your code will be merged with the master branch! :tada: