ESLint is all about rules. For most of the project’s lifetime, we’ve had over 100 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.
Core Rule Guidelines
In general, ESLint core rules must be:
- Widely applicable. The rules we distribute need to be of importance to a large number of developers. Individual preferences for uncommon patterns are not supported.
- Generic. Rules cannot be so specific that users will have trouble understanding when to use them. A rule is typically too specific if describing what it does requires more than two “and”s (if a and b and c and d, then this rule warns).
- Atomic. Rules must function completely on their own. Rules are expressly forbidden from knowing about the state or presence of other rules.
- Unique. No two rules can produce the same warning. Overlapping rules confuse end users and there is an expectation that core ESLint rules do not overlap.
- No conflicts. No rule must directly conflict with another rule. For example, if we have a rule requiring semicolons, we cannot also have a rule disallowing semicolons (which is why we have one rule,
semi, that does both).
Even though these are the formal criteria for inclusion, each rule is evaluated on its own basis.
Proposing a Rule
If you want to propose a new rule, create an issue be sure to include:
- When the rules will warn. Include a description as well as sample code.
- Whether the rule prevents an error or is stylistic.
- Why the rule should be in the core instead of creating a custom rule.
- Are you willing to create the rule yourself?
We need all of this information in order to determine whether or not the rule is a good core rule candidate.
Please keep in mind that we receive a lot of rule proposals and the ESLint team is completely a volunteer team that works in its free time to maintain ESLint. As a result, even if we like the idea for a rule, we may not have the resources to implement it. You greatly increase the likelihood of getting a new core rule into ESLint if you are willing to implement it yourself. The team is very good at guiding first-time contributors through the rule creation process.
Creating Your Own Rules
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.