- **Implementing**: There is an open pull request for each of these issues or this is a pull request that has been approved.

- **Second Review Needed**: Pull requests that already have one approval and the approver is requesting a second review before merging.

- **Merge Candidates**: Pull requests that already have at least one approval and at least one approver believes the pull request is ready to merge into the next release but would still like a TSC member to verify.

We make every attempt to automate movement between as many columns as we can, but sometimes moving issues needs to be done manually.

Each configuration object contains all of the information ESLint needs to execute on a set of files. Each configuration object is made up of these properties:

- `files` - An array of glob patterns indicating the files that the configuration object should apply to. If not specified, the configuration object applies to all files matched by any other configuration object.

- `ignores` - An array of glob patterns indicating the files that the configuration object should not apply to. If not specified, the configuration object applies to all files matched by `files`. If `ignores` is used without any other keys in the configuration object, then the patterns act as [global ignores](#globally-ignoring-files-with-ignores) and it gets applied to every configuration object.

- `extends` - An array of strings, configuration objects, or configuration arrays that contain additional configuration to apply.

ignores: [".config/", "dist/", "tsconfig.json"] // acts as global ignores, due to the absence of other properties

},

{ ... }, // ... other configuration object, inherit global ignores

]);

export default defineConfig([

globalIgnores([".config/", "dist/", "tsconfig.json"]),

{ ... }, // ... other configuration object, inherit global ignores

]);

]);

]);

For more information on how to combine predefined configs with your preferences, please see [Combine Configs](combine-configs).

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

A source code comment that configures a rule to a different severity and/or set of options.

Inline configs use similar syntax as [config files](#config-file-configuration-file) to specify any number of rules by name, their new severity, and optionally new options for the rules.

A [rule](#rule) that inspects how code operates to find problems.

You can see the full list of logical rules that ship with ESLint under [Rules > Possible Problems](../../rules/#possible-problems)

Often shareable configurations are used to enforce style guides using ESLint's built-in rules. For example the sharable configuration [eslint-config-airbnb-base](https://www.npmjs.com/package/eslint-config-airbnb-base) implements the popular Airbnb JavaScript style guide.

A popular use case for plugins is to enforce best practices for a framework. For example, [@angular-eslint/eslint-plugin](https://www.npmjs.com/package/@angular-eslint/eslint-plugin) contains best practices for using the Angular framework.

The names `"no-unused-vars"` and `"no-undef"` are the names of [rules](../rules) in ESLint. The first value is the error level of the rule and can be one of these values:

The three error levels allow you fine-grained control over how ESLint applies rules (for more configuration options and details, see the configuration docs).

{{ npm_tabs({

command: "install",

args: ["--save-dev"]

}) }}

In your `eslint.config.js` file, add:

const eslintConfigESLintCJS = require("eslint-config-eslint/cjs");

async function fetchSponsorsMarkdown() {

return got(SPONSORS_URL).text();