<commit_before>Contributing to TSLint-ESLint-Rules
===================================

 1. [Getting Involved](#getting-involved)
 2. [Reporting Bugs](#reporting-bugs)
 3. [Contributing Code](#contributing-code)
 4. [Improving Documentation](#improving-documentation)

## Getting Involved

Missing ESLint rules are always welcomed in this project, but you can also contribute with PRs for
fixing bugs or improving documentation or performance.

## Reporting Bugs

When opening a new [issue] please try to include the following information as this will make fixing
the issue easier and quicker.

 * tslint and typescript version.
   ```
   $ tslint --version
   4.0.0
   $ tsc --version
   Version 2.0.10
   ```
 * `tslint.json` configuration.
 * typescript code being linted.
 * actual behavior.
 * expected behavior.

## Contributing Code

If you are not yet familiar with the way Github works (forking, pull requests, etc.) please
check out this [article about forking](https://help.github.com/articles/fork-a-repo/). To get
started on a new rule or fix/improve some existing rule you can follow the instructions below.

- Create a branch with the rule name, e.g. `no-if-usage`.
- If you haven't, run `npm install` to download the project dependencies.
- Create your rule tests at `./src/test/rules` and your rule in `./src/rules` with the convention:
  - Name: rule-name (hyphenated, e.g: no-if-usage)
  - Rule File: ruleNameRule.ts (camelCased and with the `Rule` suffix, e.g: noIfUsageRule.ts)
  - Test File: ruleNameRuleTests.ts (camelCased and with the `RuleTests` suffix, e.g: noIfUsageRuleTests.ts)

  This step can be done automatically by running

  ```
  gulp new-rule --rule rule-name
  ```

  This will generate a the rule template and test template in the appropiate directories.

- Check if your rule is passing with `gulp test --single rule-name` (hyphenated, e.g no-inner-declarations)
  - During development you may have some linting errors that won't let you run the test. You can
    disable the linting process with the `--no-lint` flag. That is run `gulp test --single rule-name --no-lint`
  - If you are using the `RuleTester` utility as in the `ter-indent` rule tests you can specify a
    group of tests to run, for instance `gulp test --single ter-indent:call-expression`. If there
    is a particular rule from the group that needs to be tested you can also specify the index of
    the rule: `gulp test --single ter-indent:call-expression:0`.

- Make sure that all tests are passing with `gulp test`.
- Update the file `src/readme/rules.ts` with the rule information.
- Run `gulp readme` to generate the documentation.
- Run `npm test` to run all the tests once more and to self-lint our project files with the rules
  specified in `tslint_eslint_rules.json`.
- Finally, open a Pull Request.

### Commit conventions

Each commit should follow the following convention:

```
[feat] added use-isnan rule (closes #20)
```

Other commit messages include

- `[bug] fixed no-constant-condition rule (closes #9)`
- `[docs] improved README.md file (closes #32)`
- `[perf] improved valid-typeof rule (closes #48)`


## Improving Documentation

There are three type of files which can be edited to update the documentation.
<commit_msg>[docs] small change to sentence<commit_after>Contributing to TSLint-ESLint-Rules
===================================

 1. [Getting Involved](#getting-involved)
 2. [Reporting Bugs](#reporting-bugs)
 3. [Contributing Code](#contributing-code)
 4. [Improving Documentation](#improving-documentation)

## Getting Involved

Missing ESLint rules are always welcomed in this project, but you can also contribute with PRs for
fixing bugs or improving documentation or performance.

## Reporting Bugs

When opening a new [issue] please try to include the following information as this will make fixing
the issue easier and quicker.

 * tslint and typescript version.
   ```
   $ tslint --version
   4.0.0
   $ tsc --version
   Version 2.0.10
   ```
 * `tslint.json` configuration.
 * typescript code being linted.
 * actual behavior.
 * expected behavior.

## Contributing Code

If you are not yet familiar with the way Github works (forking, pull requests, etc.) please
check out this [article about forking](https://help.github.com/articles/fork-a-repo/). To get
started on a new rule or fix/improve some existing rule you can follow the instructions below.

- Create a branch with the rule name, e.g. `no-if-usage`.
- If you haven't, run `npm install` to download the project dependencies.
- Create your rule tests at `./src/test/rules` and your rule in `./src/rules` with the convention:
  - Name: rule-name (hyphenated, e.g: no-if-usage)
  - Rule File: ruleNameRule.ts (camelCased and with the `Rule` suffix, e.g: noIfUsageRule.ts)
  - Test File: ruleNameRuleTests.ts (camelCased and with the `RuleTests` suffix, e.g: noIfUsageRuleTests.ts)

  This step can be done automatically by running

  ```
  gulp new-rule --rule rule-name
  ```

  This will generate a the rule template and test template in the appropiate directories.

- Check if your rule is passing with `gulp test --single rule-name` (hyphenated, e.g no-inner-declarations)
  - During development you may have some linting errors that won't let you run the test. You can
    disable the linting process with the `--no-lint` flag: `gulp test --single rule-name --no-lint`.
  - If you are using the `RuleTester` utility as in the `ter-indent` rule tests you can specify a
    group of tests to run, for instance `gulp test --single ter-indent:call-expression`. If there
    is a particular rule from the group that needs to be tested you can also specify the index of
    the rule: `gulp test --single ter-indent:call-expression:0`.

- Make sure that all tests are passing with `gulp test`.
- Update the file `src/readme/rules.ts` with the rule information.
- Run `gulp readme` to generate the documentation.
- Run `npm test` to run all the tests once more and to self-lint our project files with the rules
  specified in `tslint_eslint_rules.json`.
- Finally, open a Pull Request.

### Commit conventions

Each commit should follow the following convention:

```
[feat] added use-isnan rule (closes #20)
```

Other commit messages include

- `[bug] fixed no-constant-condition rule (closes #9)`
- `[docs] improved README.md file (closes #32)`
- `[perf] improved valid-typeof rule (closes #48)`


## Improving Documentation

There are three type of files which can be edited to update the documentation.

{'fraction_non_alphanumeric': 0.10112014730704312, 'fraction_numerical': 0.0058309037900874635, 'mean_word_length': 3.835311572700297, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 2, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 2, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '296020', 'n_tokens_mistral': 1966, 'n_tokens_neox': 1870, 'n_words': 845}