ESLint is all about rules. For most of the project's lifetime, we've had over 200 rules, and that list continues to grow. However, we can't just accept any proposed rule because all rules need to work cohesively together. As such, we have some guidelines around which rules can be part of the ESLint core and which are better off as custom rules and plugins.
Note: As of 2020, we only accept rules related to new ECMAScript features. We prefer that new rules be implemented in plugins.
In general, ESLint core rules must be:
semi, that does both).
Even though these are the formal criteria for inclusion, each rule is evaluated on its own basis.
We need all of this information in order to determine whether or not the rule is a good core rule candidate.
In order for a rule to be accepted in the ESLint core, it must:
Keep in mind that we have over 200 rules, and that is daunting both for end users and the ESLint team (who has to maintain them). As such, any new rules must be deemed of high importance to be considered for inclusion in ESLint.
The ESLint team doesn't implement new rules that are suggested by users because we have a limited number of people and need to focus on the overall roadmap. Once a rule is accepted, you are responsible for implementing and documenting the rule. You may, alternately, recruit another person to help you implement the rule. The ESLint team member who championed the rule is your resource to help guide you through the rest of this process.
Remember that ESLint is completely pluggable, which means you can create your own rules and distribute them using plugins. We did this on purpose because we don't want to be the gatekeepers for all possible rules. Even if we don't accept a rule into the core, that doesn't mean you can't have the exact rule that you want. See the working with rules and working with plugins documentation for more information.
© JS Foundation and other contributors
Licensed under the MIT License.