ESLint installs statistics

VS Code ESLint extension

Integrates ESLint into VS Code. If you are new to ESLint check the documentation.

The extension uses the ESLint library installed in the opened workspace folder. If the folder doesn't provide one, the extension looks for a global install version. If you haven't installed ESLint either locally or globally, do so by running:

Local install (recommended):

Global install:

On new projects you might need to create an ESLint configuration file. For ESLint v9 and later (or v8.57+ with flat config), this should be one of:

• eslint.config.js (most common) • eslint.config.mjs • eslint.config.cjs • eslint.config.ts • eslint.config.mts

You can generate a starter config by running:

npx eslint --init

Example global starter settings.json:

Workspace settings can vary across projects for specific validation:

Read more about ESLint CLI.

For projects using older ESLint versions (= 8.21 = 8 || (version == 7.x && eslint.useESLintClass)).

In this example only semicolon related rules are considered:

This example removes all TypeScript ESLint specific rules from the code action on save pass but keeps all other rules:

This example keeps the indent and semi rule from TypeScript ESLint, disables all other TypeScript ESLint rules and keeps the rest:

• eslint.rules.customizations (@since 2.1.20) - force rules to report a different severity within VS Code compared to the project's true ESLint configuration. Contains these properties: • "rule": Select on rules with names that match, factoring in asterisks as wildcards: { "rule": "no-*", "severity": "warn" } • Prefix the name with a "!" to target all rules that _don't_ match the name: { "rule": "!no-*", "severity": "info" } • "severity": Sets a new severity for matched rule(s), "downgrade"s them to a lower severity, "upgrade"s them to a higher severity, or "default"s them to their original severity • "fixable": Select only autofixable rules: { "rule": "no-*", "fixable": true, "severity": "info" }

In this example, all rules are overridden to warnings:

In this example, no- rules are informative, other rules are downgraded, and "radix" is reset to default:

In this example, all autofixable rules are overridden to info:

• eslint.bulkSuppression.enable (@since 3.0.26) - enables ESlint bulk suppression. See also eslint.bulkSuppression.location and eslint.bulkSuppression.severity for additional configuration options. • eslint.format.enable (@since 2.0.0) - uses ESlint as a formatter for files that are validated by ESLint. If enabled please ensure to disable other formatters if you want to make this the default. A good way to do so is to add the following setting "[javascript]": { "editor.defaultFormatter": "dbaeumer.vscode-eslint" } for JavaScript. For TypeScript you need to add "[typescript]": { "editor.defaultFormatter": "dbaeumer.vscode-eslint" }. • eslint.onIgnoredFiles (@since 2.0.10): used to control whether warnings should be generated when trying to lint ignored files. Default is off. Can be set to warn. • editor.codeActionsOnSave (@since 2.0.0): this setting now supports an entry source.fixAll.eslint. If set to true all auto-fixable ESLint errors from all plugins will be fixed on save. You can also selectively enable and disabled specific languages using VS Code's language scoped settings. To disable codeActionsOnSave for HTML files use the following setting: The old eslint.autoFixOnSave setting is now deprecated and can safely be removed. Please also note that if you use ESLint as your default formatter you should turn off editor.formatOnSave when you have turned on editor.codeActionsOnSave. Otherwise you file gets fixed twice which in unnecessary. • eslint.problems.shortenToSingleLine: (@since 2.3.0) - Shortens the text spans of underlined problems to their first related line. • eslint.experimental.useFlatConfig: (@since 2.3.0) - Enables support of experimental Flat Config (aka eslint.config.js, supported by ESLint version 8.21 or later) • eslint.timeBudget.onValidation (@since 2.3.5) - controls the time budget that can be used for validation before a warning or an error is shown. • eslint.timeBudget.onFixes (@since 2.3.5) - controls the time budget that can be used to compute fixes before a warning or an error is shown.

Settings Migration

If the old eslint.autoFixOnSave option is set to true ESLint will prompt to convert it to the new editor.codeActionsOnSave format. If you want to avoid the migration you can respond in the dialog in the following ways:

• Not now: the setting will not be migrated by ESLint prompts again the next time you open the workspace • Never migrate Settings: the settings migration will be disabled by changing the user setting eslint.migration.2_x to off

The migration can always be triggered manually using the command ESLint: Migrate Settings

Commands:

This extension contributes the following commands to the Command palette.

• Create '.eslintrc.json' file: creates a new .eslintrc.json file. • Fix all auto-fixable problems: applies ESLint auto-fix resolutions to all fixable problems.

Using the extension with VS Code's task running

The extension is linting an individual file only on typing. If you want to lint the whole workspace set eslint.lintTask.enable to true and the extension will also contribute the eslint: lint whole folder task. There is no need any more to define a custom task in tasks.json.

Using ESLint to validate TypeScript files

A great introduction on how to lint TypeScript using ESlint can be found in the TypeScript - ESLint. Please make yourself familiar with the introduction before using the VS Code ESLint extension in a TypeScript setup. Especially make sure that you can validate TypeScript files successfully in a terminal using the eslint command.

This project itself uses ESLint to validate its TypeScript files. So it can be used as a blueprint to get started.

To avoid validation from any TSLint installation disable TSLint using "tslint.enable": false.…

Description from the VS Code Marketplace listing.