/core-rules)
    * [ Governance ](/docs/latest/contribute/governance)
    * [ Report a Security Vulnerability ](/docs/latest/contribute/report-security-vulnerability)
  * [ Maintain ESLint ](/docs/latest/maintain/)
    * [ How ESLint is Maintained ](/docs/latest/maintain/overview)
    * [ Manage Issues and Pull Requests ](/docs/latest/maintain/manage-issues)
    * [ Review Pull Requests ](/docs/latest/maintain/review-pull-requests)
    * [ Manage Releases ](/docs/latest/maintain/manage-releases)
    * [ Working Groups ](/docs/latest/maintain/working-groups)

#  Configure Rules

##  Table of Contents

  1. Rule Severities 
    1. Using configuration comments 
      1. Configuration Comment Descriptions 
    2. Using Configuration Files 
  2. Rules from Plugins 
  3. Disabling Rules 
    1. Using configuration comments 
      1. Comment descriptions 
    2. Using configuration files 
    3. Disabling Inline Comments 
      1. Report unused eslint-disable comments 

Tip

This page explains how to configure rules using the flat config format. For
the deprecated eslintrc format, [ see the deprecated documentation ](rules-
deprecated) .

Rules are the core building block of ESLint. A rule validates if your code
meets a certain expectation, and what to do if it does not meet that
expectation. Rules can also contain additional configuration options specific
to that rule.

ESLint comes with a large number of [ built-in rules ](../../rules/) and you
can add more rules through plugins. You can modify which rules your project
uses with either configuration comments or configuration files.

##  Rule Severities

To change a rule’s severity, set the rule ID equal to one of these values:

  * ` "off" ` or ` 0 ` \- turn the rule off 
  * ` "warn" ` or ` 1 ` \- turn the rule on as a warning (doesn’t affect exit code) 
  * ` "error" ` or ` 2 ` \- turn the rule on as an error (exit code is 1 when triggered) 

Rules are typically set to ` "error" ` to enforce compliance with the rule
during continuous integration testing, pre-commit checks, and pull request
merging because doing so causes ESLint to exit with a non-zero exit code.

If you don’t want to enforce compliance with a rule but would still like
ESLint to report the rule’s violations, set the severity to ` "warn" ` . This
is typically used when introducing a new rule that will eventually be set to `
"error" ` , when a rule is flagging something other than a potential buildtime
or runtime error (such as an unused variable), or when a rule cannot determine
with certainty that a problem has been found (when a rule might have false
positives and need manual review).

###  Using configuration comments

To configure rules inside of a file using configuration comments, use a
comment in the following format:

    
    
    /* eslint eqeqeq: "off", curly: "error" */
    
    
    1  
    

In this example, [ ` eqeqeq ` ](../../rules/eqeqeq) is turned off and [ `
curly ` ](../../rules/curly) is turned on as an error. You can also use the
numeric equivalent for the rule severity:

    
    
    /* eslint eqeqeq: 0, curly: 2 */
    
    
    1  
    

This example is the same as the last example, only it uses the numeric codes
instead of the string values. The ` eqeqeq ` rule is off and the ` curly `
rule is set to be an error.

If a rule has additional options, you can specify them using array literal
syntax, such as:

    
    
    /* eslint quotes: ["error", "double"], curly: 2 */
    
    
    1  
    

This comment specifies the “double” option for the [ ` quotes `
](../../rules/quotes) rule. The first item in the array is always the rule
severity (number or string).

####  Configuration Comment Descriptions

Configuration comments can include descriptions to explain why the comment is
necessary. The description must occur after the configuration and is separated
from the configuration by two or more consecutive ` - ` characters. For
example:

    
    
    /* eslint eqeqeq: "off", curly: "error"