Skip to content

docs(website): added maintenance docs for rule feature requests #6254

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Jan 30, 2023
Merged

docs(website): added maintenance docs for rule feature requests #6254

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
36 changes: 32 additions & 4 deletions docs/maintenance/ISSUES.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -93,13 +93,41 @@ These bugs should be reported with a link to a GitHub repository that can be che
If you cannot reproduce the issue as described using repository's README.md and issue description, it has not provided enough information.
Consider using a specific response like the _Needs Full Reproduction_ response.

### ✨ Rule Enhancements
### 🏗 Feature Requests

TODO: This will be filled out... soon!
For any feature request, make sure the requested support is either:

### 🚀 New Rules
- Very useful for at least one commonly used way to run TypeScript (e.g. tsc-built CLI package; bundler-managed web app)
- Relevant for _most_ projects that would be using typescript-eslint

TODO: This will be filled out... soon!
We avoid features that:

- Are only relevant for a minority of users, as they aren't likely worth the maintenance burden
- Aren't TypeScript-specific (e.g. should be in ESLint core instead)
- Are only relevant with specific userland frameworks or libraries, such as Jest or React
- Are for "formatting" functionality (we [strongly recommend users use a separate dedicated formatter](../linting/troubleshooting/FORMATTING.md))

#### ✨ Rule Enhancements

We're generally accepting of rule enhancements that meet the above feature request criteria.
If a rule enhancement would substantially change the target area of the rule, consider whether it should instead be a new rule.
Common signs of this are the rule's original name now being inaccurate, or some options being relevant just for the old functionality.

Enhancements that can cause new reports to be reported are considered breaking changes.
We have two common strategies for them:

- Treat the enhancement as a breaking change, and block merging it until the next major version
- Add an option to disable the new logic: which is a breaking change if opt-in, and a non-breaking change if opt-out
- Add an option to enable the new logic: which is a breaking change if opt-out, and a non-breaking change if opt-in

See [Can we standardize logical direction of rule options?](https://github.com/typescript-eslint/typescript-eslint/discussions/6101) for context on naming options.

For enhancements meant to limit which kinds of nodes the rule targets, mark the issue as blocked on [RFC: Common format to specify a type or value as a rule option](https://github.com/typescript-eslint/typescript-eslint/discussions/6017).

#### 🚀 New Rules

We're generally accepting of new rules that meet the above feature request criteria.
The biggest exception is rules that can roughly be implemented with [`@typescript-eslint/ban-types`](https://typescript-eslint.io/rules/ban-types) and/or [`no-restricted-syntax`](https://eslint.org/docs/latest/rules/no-restricted-syntax).

## Pruning Old Issues

Expand Down