# Developer Guide
Contributing is welcome.
# 🐛 Bug reporting
If you think you’ve found a bug in ESLint, please create a new issue or a pull request on GitHub.
Please include as much detail as possible to help us properly address your issue. If we need to triage issues and constantly ask people for more detail, that’s time taken away from actually fixing issues. Help us be as efficient as possible by including a lot of detail in your issues.
# ✨ Proposing a new rule or a rule change
In order to add a new rule or a rule change, you should:
- Create issue on GitHub with description of proposed rule
- Write test scenarios & implement logic
- Describe the rule in the
docsfolder - Make sure all tests are passing
- Run
npm run testand fix any errors - Create PR and link created issue in description
We're more than happy to see potential contributions, so don't hesitate. If you have any suggestions, ideas or problems feel free to add new issue, but first please make sure your question does not repeat previous ones.
# 🔥 Working with rules
Before you start writing new rule, please read the official ESLint guide.
Next in order to get an idea how does the AST of the code that you want to check looks like, you can use one of the following applications:
- astexplorer.net - best tool to inspect ASTs
Check out an example rule to get a better understanding of how these work.
Please be aware that regarding what kind of code examples you'll write in tests, you'll have to accordingly setup the parser in RuleTester (you can do it on per test case basis though). See an example here