Home

Awesome

VS Code ESLint extension

Build Status

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 npm install eslint in the workspace folder for a local install or npm install -g eslint for a global install.

On new folders you might also need to create an .eslintrc configuration file. You can do this by either using the VS Code command Create ESLint configuration or by running the eslint command in a terminal with npx eslint --init.

Index

Release Notes

This section describes major releases and their improvements. For a detailed list of changes please refer to the change log.

From version 2.2.3 on forward odd minor or patch version numbers indicate an insider or pre-release. So versions 2.2.3, 2.2.5 and 2.3.1 will all be pre-release versions. 2.2.10, 2.4.10 and 3.0.0 will all be regular release versions.

Version 3.0.13 - pre-release

Version 3.0.11 - pre-release

Version 3.0.10 - release

Version 3.0.8 - release

Version 3.0.5 - pre-release

Version 2.4.4

Version 2.4.3 - pre-release

Version 2.4.2

Version 2.4.1 - Pre-release

Version 2.4.0 (same as 2.3.5 - Pre-release)

Version 2.3.5 - Pre-release

Version 2.3.3 - Pre-release

Version 2.3.1 - Pre-release (internal only)

Version 2.3.0 - Pre-release

Version 2.2.6 (same as 2.2.5 Pre-release)

Version 2.2.5 - Pre-release

Version 2.2.0

Added support for ESLint V8.0 Beta. To stay backwards compatible with eslint settings the version still uses the CLIEngine if available. However users can force the use of the new ESLint API using the setting eslint.useESLintClass. Beware that the ESLint npm module changed how options are interpreted. It also changed the names of certain options. If you used eslint.options to pass special options to the ESLint npm module you might need to adapt the setting to the new form.

Version 2.1.22

Adapt VS Code's workspace trust model. As a consequence the custom dialog ESLint introduced in version 2.1.7 got removed. In addition the off value got added to the eslint rule customization support.

Version 2.1.20

Added support to customize the severity of eslint rules. See the new setting eslint.rules.customizations.

Version 2.1.18

Asking for confirmation of the eslint.nodePath value revealed a setup where that value is defined separately on a workspace folder level although a multi workspace folder setup is open (e.g. a code-workspace file). These setups need to define the eslint.nodePath value in the corresponding code-workspace file and the extension now warns the user about it. Below an example of such a code-workspace file

{
        "folders": [
                {
                        "path": "project-a"
                },
                {
                        "path": "project-b"
                }
        ],
        "settings": {
                "eslint.nodePath": "myCustomNodePath"
        }
}

Version 2.1.17

To follow VS Code's model to confirm workspace local settings that impact code execution the two settings eslint.runtime and eslint.nodePath now need user confirmation if defined locally in a workspace folder or a workspace file. Users using these settings in those local scopes will see a notification reminding them of the confirmation need.

The version also adds a command to restart the ESLint server.

Version 2.1.10

The approval flow to allow the execution of a ESLint library got reworked. Its initial experience is now as follows:

The execution of the ESLint library can be denied or approved using the following gestures:

All gestures will open the following dialog:

ESLint Dialog

The chosen action is then reflected in the ESLint status bar item in the following way:

You can manage our decisions using the following commands:

This release also addresses the vulnerability described in CVE-2021-27081.

Version 2.0.4

The 2.0.4 version of the extension contains the following major improvements:

The setting below turns on Auto Fix for all providers including ESLint:

    "editor.codeActionsOnSave": {
        "source.fixAll": "explicit"
    }

In contrast, this configuration only turns it on for ESLint:

    "editor.codeActionsOnSave": {
        "source.fixAll.eslint": "explicit"
    }

You can also selectively disable ESLint via:

    "editor.codeActionsOnSave": {
        "source.fixAll": "explicit",
        "source.fixAll.eslint": "never"
    }

Also note that there is a time budget of 750ms to run code actions on save which might not be enough for large JavaScript / TypeScript file. You can increase the time budget using the editor.codeActionsOnSaveTimeout setting.

The old eslint.autoFixOnSave setting is now deprecated and can safely be removed.

Settings Options

If you are using an ESLint extension version < 2.x then please refer to the settings options here.

This extension contributes the following variables to the settings:

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:

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

Commands:

This extension contributes the following commands to the Command palette.

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.

Mono repository setup

As with JavaScript validating TypeScript in a mono repository requires that you tell the VS Code ESLint extension what the current working directories are. Use the eslint.workingDirectories setting to do so. For this repository the working directory setup looks as follows:

	"eslint.workingDirectories": [ "./client", "./server" ]

ESLint 6.x

Migrating from ESLint 5.x to ESLint 6.x might need some adaption (see the ESLint Migration Guide for details). Before filing an issue against the VS Code ESLint extension please ensure that you can successfully validate your files in a terminal using the eslint command.