Download Eslint For Vscode
Angeles Bartholomew
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.
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.
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
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.
eslint.debug: enables ESLint's debug mode (same as --debug command line option). Please see the ESLint output channel for the debug output. This options is very helpful to track down configuration and installation problems with ESLint since it provides verbose information about how ESLint is validating a file.
eslint.lintTask.options: Command line options applied when running the task for linting the whole workspace ( -guide/command-line-interface).An example to point to a custom .eslintrc.json file and a custom .eslintignore is:
The old eslint.packageManager setting is now deprecated and can safely be removed. This controlled the package manager to be used to resolve the ESLint library. This has only an influence if the ESLint library is resolved globally. Valid values are "npm" or "yarn" or "pnpm".
eslint.options: options to configure how ESLint is started using either the ESLint class API or the CLIEngine API. The extension uses the ESLint class API if ESLint version 8 or higher is used or if ESLint version 7 is used and the setting eslint.useESLintCLass is set to true. In all other cases the CLIEngine API is used.An example to point to a custom .eslintrc.json file using the new ESLint API is:
eslint.probe - an array for language identifiers for which the ESLint extension should be activated and should try to validate the file. If validation fails for probed languages the extension says silent. Defaults to ["javascript", "javascriptreact", "typescript", "typescriptreact", "html", "vue", "markdown"].
eslint.validate - an array of language identifiers specifying the files for which validation is to be enforced. This is an old legacy setting and should in normal cases not be necessary anymore. Defaults to ["javascript", "javascriptreact"].
eslint.format.enable: enables ESLint as a formatter for validated files. Although you can also use the formatter on save using the setting editor.formatOnSave it is recommended to use the editor.codeActionsOnSave feature since it allows for better configurability.
eslint.workingDirectories - specifies how the working directories ESLint is using are computed. ESLint resolves configuration files (e.g. eslintrc, .eslintignore) relative to a working directory so it is important to configure this correctly. If executing ESLint in the terminal requires you to change the working directory in the terminal into a sub folder then it is usually necessary to tweak this setting. (see also ESLint class options#cwd). Please also keep in mind that the .eslintrc* file is resolved considering the parent directories whereas the .eslintignore file is only honored in the current working directory. The following values can be used:
eslint.codeActionsOnSave.rules (@since 2.2.0) - controls the rules which are taken into consideration during code action on save execution. If not specified all rules specified via the normal ESLint configuration mechanism are consider. An empty array results in no rules being considered. If the array contains more than one entry the order matters and the first match determines the rule's on / off state. This setting is only honored under the following cases:
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" .
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.
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 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.
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.
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:
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.
Once you have a eslintrc file provided (either created by yourself or provided internally by a tool like create-react-app), you can make the ESLint warnings/errors visible in VS Code by installing the ESLint extension from the VS Code Marketplace.
Using the npm init command to initialize your project will create a package.json file in the vscode-eslint-example directory. The package.json will store your project dependencies and other important configuration settings for your project.
An important piece in this command is the --init flag. The ./node_modules/.bin/eslint section of the command is the path to ESLint in your project. Using the --init flag activates ESLint for your project. Activating or initializing ESLint will create an ESLint configuration file that will allow you to customize how ESLint works with your project.
As is, ESLint produces a highlighted message for all console.log() statements in app.js. In some cases, removing console.log statements may not be a priority. You can customize the ESLint configuration to allow console.log statements without producing an error message. ESLint configuration rules can be modified in the .eslintrc.json file.
There should now be a new .eslintrc.js file, a log file (tslint-to-eslint-config.log), and likely changes to other files, like .vscode/settings.json. Carefully review the changes, especially those made to existing files, and check the log file.
The .eslintrc.js file is usually sufficient to get started but it's likely that the parserOptions.project property is still set to your tsconfig.json file. That means that ESLint rules can use semantic information, for example, is this variable a string or a number-array? This configuration enables some powerful rules but means that ESLint takes much longer to compute. The default rules for extensions do not require semantic information and unless you have added rules that do, we recommend you remove the parserOptions.project property.
It is time to lint! Use this command: eslint -c .eslintrc.js --ext .ts (notice the --ext .ts option which tells ESLint to look at TypeScript files). We recommend putting the command in the scripts section of your package.json-file, like so:
Everytime I open my project folder in Visual Studio Code, I get an error on the first line of each file. It cannot find my tsconfig.json file because it is looking in the directory I opened VS Code, not where my eslint.json is. I have a functions folder in my root project where the ESLint config is.
When I run my lint command eslint "src/*.ts,js", it works perfectly and shows the correct warnings. This means that the VS Code plugin dbaeumer.vscode-eslint parses the .eslintrc.json config differently than what it should.
df19127ead