Initial commit

README.md

@@ -0,0 +1,150 @@
+
+![Logo of the project](./logo.png)
+
+# Project Guidelines
+- [Git](#git)
+- [Documentation](#documentation)
+- [Environments](#environments)
+- [Dev Environment](#dev)
+- [Dependencies](#dependencies)
+- [Testing](#testing)
+- [Structure and Naming](#structure)
+- [Code style](#code_style)
+- [Logging](#logging)
+- [Licensing](#licensing)
+
+## <a name="git"></a>1. Git
+* We use GitFlow, read more here [A successful Git branching model » nvie.com](http://nvie.com/posts/a-successful-git-branching-model/)
+* Resolve potential conflicts before making a Pull Request
+* Never Push into `develop` branch.
+* Keep your `develop` and  `master` update.
+* Make a Pull Requests to develop only if your build have been successful on your machine (this includes passing tests and [code style](#code style) checks )
+* Merge your pull requests only after receiving approval from at least one of your team members.
+* Use [hive’s .gitignore file](./README.sample.md).
+* Make sure your `.gitignore` exclude the following from Repo
+	* `.env` or any file containing passwords, keys, tokens or anything similar used in production
+	* Your editor config files (.idea, .vscode etc…)
+	* Any generated file (compiled sources, build outputs, logs)
+	* You dependencies directory (node_modules, bower_components etc…)
+	* OS folder view configuration (.DS_STORE, Desktop.ini etc…)
+	* Thumbnail cache files (._*,  Thumbs.db etc…)
+
+## <a name="documentation"></a>2. Documentation
+* Follow hive’s  `README.md` template for start (add extra sections if necessary). [hive’s README.md template](./README.sample.md)
+* If project is broken down into more than one repo, provide links in the  `README.md` file.
+* Keep `README.md` updated
+* Comment all your code to make it as clear as possible how your app works, and what you are intending with each major section. 
+* Update your comments
+
+## <a name="environments"></a>3. Environmental Awareness
+* Depending on project size, define separate `development`, `test` and `production`  environments. 
+* Load your deployment specific configurations from environment variables and never add them to the codebase as constants, [look at this sample](./config.sample.js).
+*  Your config should be correctly separated from the apps internals if the codebase could be made public at any moment.  Use `.env` files to store your variables and add them to `gitignore` to be excluded from your code base because of course, you want the environment to provide them. Instead commit a `.env.example`  which serves as a guide for developers to know which environment variables the project needs. It is important to remember that this setup should only be used for development. For production you should still set your environment variables in the standard way.
+* It’s recommended to validate environment variables before your app starts ,  [look at this sample](./configWithTest.sample.js) using `joi` to validate provided values: 
+
+## <a name="dev"></a>4. Dev Environment
+### 4.1 Consistent dev environments:
+* Use `engines` in `package.json` to specify the version of node that your stuff works on.
+* Use `nvm` and create a  `.nvmrc`  in your project root.  Mention in documentation
+* Use a `preinstall` script that checks node and npm versions
+* Or if it doesn’t make things complicated use a docker images 
+* Local modules instead of requiring global installation
+
+### 4.2 Consistent dependencies:
+* Use `package-lock.json` on npm 5 and later
+* For older versions of npm Use `—save --save-exact` when installing a new dependency and create `npm-shrinkwrap.json` before publishing.
+* If you use `Yarn` make sure to mention it in `README.md`. Your lock file and `package.json` should have the same versions after each dependency upgrade.
+* Read more [package-locks | npm Documentation](https://docs.npmjs.com/files/package-locks)
+
+## <a name="dependencies"></a>5. Dependencies
+Before using a package check its Github open issues, daily downloads and number of contributors as well as the date package last updated.
+If less known dependency is needed,  discuss it with the team before using it.
+
+* Which packages am I using? And for each one... [ls | npm Documentation](https://docs.npmjs.com/cli/ls)
+* Am I still using this package?[depcheck](https://www.npmjs.com/package/depcheck) Always get rid of unused packages
+* Are other developers using this package? [npm-stat: download statistics for NPM packages](https://npm-stat.com/)
+* Am I using the latest version of this package? [outdated | npm Documentation](https://docs.npmjs.com/cli/outdated)
+* When was this package last updated? [view | npm Documentation](https://docs.npmjs.com/cli/view)
+* How many maintainers do these packages have? [view | npm Documentation](https://docs.npmjs.com/cli/view)
+* Does this package have known security vulnerabilities? [Test | Snyk](https://snyk.io/test?utm_source=risingstack_blog)
+
+## <a name="testing"></a>6. Testing
+* Have a test mode environment if needed.
+* Place your test files next to the tested modules using `*.test.js` or `*.spec.js` naming convention, like `module_name.spec.js`
+* Put your additional test files to a separate test folder to avoid confusion.
+* write testable code, avoid side effect, extract side effects, write pure functions
+* Don’t write too many tests to check types, instead use a Static type checker
+* Run tests locally before any pull request to `develop`.
+
+## <a name="structure"></a>7. Structure and Naming
+* Organise your files around product features / pages / components, not Roles:
+
+```
+// BAD 
+.
+├── controllers
+|   ├── product.js
+|   └── user.js
+├── models
+|   ├── product.js
+|   └── user.js
+```
+
+```
+// GOOD
+.
+├── product
+|   ├── index.js
+|   ├── product.js
+|   └── product.test.js
+├── user
+|   ├── index.js
+|   ├── user.js
+|   └── user.test.js
+```
+
+* Place Your Test Files Next to The Implementation
+* Put your additional test files to a separate test folder to avoid confusion.
+* Use a `./config` directory
+* Put Your Long `npm` Scripts in a `./scripts` directory. This is for bash and node scripts for database synchronisation, front-end build scripts and so on. 
+* Put your compiled or built output in a `./build` folder
+* Use `PascalCase/camelCase` for filenames and directory names too. Which  `PascalCase`  is for Components.
+* `CheckBox/index.js` should have the `CheckBox` component, as could `CheckBox.js`, but **not** `CheckBox/CheckBox.js` or `checkbox/CheckBox.js`
+* Ideally the directory name would match the name of the default export of `index.js`
+
+## <a name="code_style"></a>8. Code style
+* Use latest stablished JavaScript syntax for new projects
+* Include code style check before build process
+* Use [ESLint - Pluggable JavaScript linter](http://eslint.org/) to enforce code style
+* Use [Airbnb JavaScript Style Guide](https://github.com/airbnb/javascript) for JavaScript.  [Read more · GitBook](https://www.gitbook.com/book/duk/airbnb-javascript-guidelines/details) 
+* Use [Flow type linting rules for ESLint.](https://github.com/gajus/eslint-plugin-flowtype) for [FlowType](https://flow.org/)
+* Use `.eslintignore` to exclude file or folders from linting. 
+* Remove your `eslint` disable comments before making a Pull Request
+* Always use  `//todo:`  comments to remind yourself and others about an unfinished job
+* Always comment and keep them relevant as code changes 
+* Remove commented block of code when possible
+* Avoid console logs on client side code in production
+* Avoid alerts in production
+* Avoid irrelevant or funny comments, logs or naming.
+* Write testable code, avoid side effect, extract side effects, write pure functions
+* Make your names searchable with meaningful distinctions avoid shortened names. For functions Use long, descriptive names. A function name should be a verb or a verb phrase, and it needs to communicate its intention
+* Organise your functions in a file according to the stepdown rule. Higher level functions should be on top and lower levels below. It makes it natural to read the source code.
+
+## <a name="logging"></a>9. Logging
+* Avoid client side console logs in production
+* Produce readable production logging. Ideally use production logging libraries to be used in production mode.
+
+## <a name="licensing"></a>10. Licensing
+Make sure you use resources that you have the rights to use. Copyrighted images and videos, for example, could cause legal problems.
+
+
+---
+Sources:
+[RisingStack Engineering](https://blog.risingstack.com/), 
+[Mozilla Developer Network](https://developer.mozilla.org/), 
+[Heroku Dev Center](https://devcenter.heroku.com), 
+[airbnb/javascript](https://github.com/airbnb/javascript)
+
+
+
+© WeAreHive Limited

README.sample.md

@@ -0,0 +1,101 @@
+![Logo of the project](./logo.sample.png)
+
+# Name of the project
+> Additional information or tagline
+
+A brief description of your project, what it is used for.
+
+## Installing / Getting started
+
+A quick introduction of the minimal setup you need to get a hello world up &
+running.
+
+```shell
+commands here
+```
+
+Here you should say what actually happens when you execute the code above.
+
+## Developing
+
+### Built With
+List main libraries, frameworks used including versions (React, Angular etc...)
+
+### Prerequisities
+What is needed to set up the dev environment. For instance, global dependencies or any other tools. include download links.
+
+
+### Setting up Dev
+
+Here's a brief intro about what a developer must do in order to start developing
+the project further:
+
+```shell
+git clone https://github.com/your/your-project.git
+cd your-project/
+packagemanager install
+```
+
+And state what happens step-by-step. If there is any vistual environment, local server or database feeder needed, explain here.
+
+### Building
+
+If your project needs some additional steps for the developer to build the
+project after some code changes, state them here. for example:
+
+```shell
+./configure
+make
+make install
+```
+
+Here again you should state what actually happens when the code above gets
+executed.
+
+### Deploying / Publishing
+give instructions on how to build and release a new version
+In case there's some step you have to take that publishes this project to a
+server, this is the right time to state it.
+
+```shell
+packagemanager deploy your-project -s server.com -u username -p password
+```
+
+And again you'd need to tell what the previous code actually does.
+
+## Versioning
+
+We can maybe use [SemVer](http://semver.org/) for versioning. For the versions available, see the [link to tags on this repository](/tags).
+
+
+## Configuration
+
+Here you should write what are all of the configurations a user can enter when
+using the project.
+
+## Tests
+
+Describe and show how to run the tests with code examples.
+Explain what these tests test and why.
+
+```shell
+Give an example
+```
+
+## Style guide
+
+Explain your code style and show how to check it.
+
+## Api Reference
+
+If the api is external, link to api doscumentation. If not descripe your api including authentication methods as well as explaining all the endpoints with their required parameters.
+
+
+## Databese
+
+Explaining what database (and version) has been used. Provide download links.
+Documents your database design and schemas, relations etc... 
+
+## Licensing
+
+State what the license is and how to find the text version of the license.

config.sample.js

@@ -0,0 +1,23 @@
+// required environment variables
+[
+  'NODE_ENV',
+  'PORT'
+].forEach((name) => {
+  if (!process.env[name]) {
+    throw new Error(`Environment variable ${name} is missing`)
+  }
+})
+
+const config = {  
+  env: process.env.NODE_ENV,
+  logger: {
+    level: process.env.LOG_LEVEL || 'info',
+    enabled: process.env.BOOLEAN ? process.env.BOOLEAN.toLowerCase() === 'true' : false
+  },
+  server: {
+    port: Number(process.env.PORT)
+  }
+  // ...
+}
+
+module.exports = config;

configWithTest.sample.js

@@ -0,0 +1,40 @@
+const joi = require('joi')
+
+const envVarsSchema = joi.object({  
+  NODE_ENV: joi.string()
+    .allow(['development', 'production', 'test', 'provision'])
+    .required(),
+  PORT: joi.number()
+    .required(),
+  LOGGER_LEVEL: joi.string()
+    .allow(['error', 'warn', 'info', 'verbose', 'debug', 'silly'])
+    .default('info'),
+  LOGGER_ENABLED: joi.boolean()
+    .truthy('TRUE')
+    .truthy('true')
+    .falsy('FALSE')
+    .falsy('false')
+    .default(true)
+}).unknown()
+  .required()
+
+const { error, value: envVars } = joi.validate(process.env, envVarsSchema)  
+if (error) {  
+  throw new Error(`Config validation error: ${error.message}`)
+}
+
+const config = {  
+  env: envVars.NODE_ENV,
+  isTest: envVars.NODE_ENV === 'test',
+  isDevelopment: envVars.NODE_ENV === 'development',
+  logger: {
+    level: envVars.LOGGER_LEVEL,
+    enabled: envVars.LOGGER_ENABLED
+  },
+  server: {
+    port: envVars.PORT
+  }
+  // ...
+}
+
+module.exports = config;