# How to Contribute

First of all, thank you for your interest in thedebugger!
We'd love to accept your patches and contributions!

## Getting setup

1. Clone this repository

```bash
git clone https://github.com/sfninja/thedebugger
cd thedebugger
```

2. Install dependencies

```bash
npm install
```

## Code reviews

All submissions, including submissions by project members, require review. We
use GitHub pull requests for this purpose. Consult
[GitHub Help](https://help.github.com/articles/about-pull-requests/) for more
information on using pull requests.

## Code Style

- Coding style is fully defined in [.eslintrc](https://github.com/sfninja/thedebugger/blob/master/.eslintrc.js)
- Code should be annotated with [closure annotations](https://github.com/google/closure-compiler/wiki/Annotating-JavaScript-for-the-Closure-Compiler).
- Comments should be generally avoided. If the code would not be understood without comments, consider re-writing the code to make it self-explanatory.

To run code linter, use:

```bash
npm run lint
```

## Commit Messages

Commit messages should follow the Semantic Commit Messages format:

```
label(namespace): title

description

footer
```

1. *label* is one of the following:
    - `fix` - thedebugger bug fixes.
    - `feat` - thedebugger features.
    - `docs` - changes to docs, e.g. `docs(api.md): ..` to change documentation.
    - `test` - changes to thedebugger tests infrastructure.
    - `style` - thedebugger code style: spaces/alignment/wrapping etc.
    - `chore` - build-related work.
2. *namespace* is put in parenthesis after label and is **optional**.
3. *title* is a brief summary of changes.
4. *description* is **optional**, new-line separated from title and is in present tense.
5. *footer* is **optional**, new-line separated from *description* and contains "fixes" / "references" attribution to github issues.

Example:

```
fix(NddService): fix NddService.attach method

This patch fixes NddService.attach so that it works with Node 12.

Fixes #123, Fixes #234
```

## Adding New Dependencies

For all dependencies (both installation and development):
- **Do not add** a dependency if the desired functionality is easily implementable.
- If adding a dependency, it should be well-maintained and trustworthy.

A barrier for introducing new installation dependencies is especially high:
- **Do not add** installation dependency unless it's critical to project success.

## Developing thedebugger hints

- Environment variable NDB_DEBUG_FRONTEND=1 forces thedebugger to fetch
frontend from front_end folder and chrome-devtools-frontend
package.

```bash
NDB_DEBUG_FRONTEND=1 thedebugger .
```

- To debug ndb by itself or any thedebugger service you can use thedebugger.
```bash
NDB_DEBUG_FRONTEND=1 thedebugger thedebugger index.js
```

- To debug running Chrome DevTools frontend you can open DevTools,
use Ctrl+Shift+I on Linux or View > Developer > Developer Tools menu
item on Mac OS.