# Best Practices

## Linting

### ESLint

This project uses Airbnb's ESLint configuration as a base. On top of that, it's
configured to work with Typescript. Airbnb's standard is great to guarantee
code consistency and early error detection. You won't be able to commit files
with linting errors, sorry 😞.

However, sometimes it can be pretty harsh. Feel free to disable specific rules
in your files if you really need to and let's discuss overriding rules globally
if they interfere with our daily coding. No rule is useful if it gets in the
middle.

If you are using **VS Code**, you should install ESLint extension. Not only it
will show you linting errors but also you can set it to fix some of them on
save. To do so, edit your `settings.json` config file and add the following:

    "eslint.autoFixOnSave": true,
    "eslint.alwaysShowStatus": true,
    "eslint.validate": [
      "javascript",
      "javascriptreact",
      {
        "language": "typescript",
        "autoFix": true
      },
      {
        "language": "typescriptreact",
        "autoFix": true
      }
    ]

### Markdown

For more information, refer to this repository: <https://github.com/DavidAnson/markdownlint>

## Branches

- `master` is our main branch for nightly builds
- Try to not develop directly on `master` branch
- merges to `master` should be through `pull request` practice.

### Branch naming

- `poc/branch-name` for proof of concepts
- `feature/branch-name` for new features like, components, services, validations,
flows, etc.
- `docs/branch-name` for new documentation or updates
- `bugfix/branch-name` for bugfixing code
- `hotfix/branch-name` for bugfixing in prod/staging

## Commits

We use [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/)
specification. This will allow us to create automatized changelogs and semantic
versioning. Because of this, you won't be able to commit messages that do not
follow this specification.

### Example

feat: added hat wobble
^--^  ^---------------^
|     |
|     +-> Summary in past simple tense.
|
+-------> Type: chore, docs, feat, fix, refactor, style, or test.

### Types

- `feat`: (new feature for the user, not a new feature for build script)
- `fix`: (bug fix for the user, not a fix to a build script)
- `docs`: (changes to the documentation)
- `style`: (formatting, missing semicolons, etc; no production code change)
- `refactor`: (refactoring production code, eg. renaming a variable)
- `test`: (adding missing tests, refactoring tests; no production code change)
- `chore`: (updating grunt tasks etc; no production code change)