Here are the Top 5 React JS useful Visual Studio Code extensions:

1. ReactJs code snippets: This extension provides a set of helpful code snippets for React development, making it easier and faster to write React components. It includes snippets for things like creating stateful and stateless components, lifecycle methods, and more.

Installation

In order to install an extension you need to launch the Command Palette (Ctrl + Shift + P or Cmd + Shift + P) and type Extensions. There you have either the option to show the already installed snippets or install new ones.

Supported languages (file extensions)

• JavaScript (.js)
• TypeScript (.ts)
• JavaScript React (.jsx)
• TypeScript React (.tsx)

Snippets 

Below is a list of all available snippets and the triggers of each one. The ⇥ means the TAB key.

Trigger	Content
rcc→	class component skeleton
rrc→	class component skeleton with react-redux connect
rrdc→	class component skeleton with react-redux connect and dispatch
rccp→	class component skeleton with prop types after the class
rcjc→	class component skeleton without import and default export lines
rcfc→	class component skeleton that contains all the lifecycle methods
rwwd→	class component without import statements
rpc→	class pure component skeleton with prop types after the class
rsc→	stateless component skeleton
rscp→	stateless component with prop types skeleton
rscm→	memoize stateless component skeleton
rscpm→	memoize stateless component with prop types skeleton
rsf→	stateless named function skeleton
rsfp→	stateless named function with prop types skeleton
rsi→	stateless component with prop types and implicit return
fcc→	class component with flow types skeleton
fsf→	stateless named function skeleton with flow types skeleton
fsc→	stateless component with flow types skeleton
rpt→	empty propTypes declaration
rdp→	empty defaultProps declaration
con→	class default constructor with props
conc→	class default constructor with props and context
est→	empty state object
cwm→	componentWillMount method
cdm→	componentDidMount method
cwr→	componentWillReceiveProps method
scu→	shouldComponentUpdate method
cwup→	componentWillUpdate method
cdup→	componentDidUpdate method
cwun→	componentWillUnmount method
gsbu→	getSnapshotBeforeUpdate method
gdsfp→	static getDerivedStateFromProps method
cdc→	componentDidCatch method
ren→	render method
sst→	this.setState with object as parameter
ssf→	this.setState with function as parameter
props→	this.props
state→	this.state
bnd→	binds the this of method inside the constructor
disp→	MapDispatchToProps redux function

The following table lists all the snippets that can be used for prop types. Every snippet regarding prop types begins with pt so it's easy to group it all together and explore all the available options. On top of that each prop type snippets has one equivalent when we need to declare that this property is also required.

For example pta creates the PropTypes.array and ptar creates the PropTypes.array.isRequired

Trigger	Content
pta→	PropTypes.array,
ptar→	PropTypes.array.isRequired,
ptb→	PropTypes.bool,
ptbr→	PropTypes.bool.isRequired,
ptf→	PropTypes.func,
ptfr→	PropTypes.func.isRequired,
ptn→	PropTypes.number,
ptnr→	PropTypes.number.isRequired,
pto→	PropTypes.object,
ptor→	PropTypes.object.isRequired,
pts→	PropTypes.string,
ptsr→	PropTypes.string.isRequired,
ptsm→	PropTypes.symbol,
ptsmr→	PropTypes.symbol.isRequired,
ptan→	PropTypes.any,
ptanr→	PropTypes.any.isRequired,
ptnd→	PropTypes.node,
ptndr→	PropTypes.node.isRequired,
ptel→	PropTypes.element,
ptelr→	PropTypes.element.isRequired,
pti→	PropTypes.instanceOf(ClassName),
ptir→	PropTypes.instanceOf(ClassName).isRequired,
pte→	PropTypes.oneOf(['News', 'Photos']),
pter→	PropTypes.oneOf(['News', 'Photos']).isRequired,
ptet→	PropTypes.oneOfType([PropTypes.string, PropTypes.number]),
ptetr→	PropTypes.oneOfType([PropTypes.string, PropTypes.number]).isRequired,
ptao→	PropTypes.arrayOf(PropTypes.number),
ptaor→	PropTypes.arrayOf(PropTypes.number).isRequired,
ptoo→	PropTypes.objectOf(PropTypes.number),
ptoor→	PropTypes.objectOf(PropTypes.number).isRequired,
ptoos→	PropTypes.objectOf(PropTypes.shape()),
ptoosr→	PropTypes.objectOf(PropTypes.shape()).isRequired,
ptsh→	PropTypes.shape({color: PropTypes.string, fontSize: PropTypes.number}),
ptshr→	PropTypes.shape({color: PropTypes.string, fontSize: PropTypes.number}).isRequired,

Letast Version Download {click download}

2. ES7 React/Redux/GraphQL/React-Native snippets: This extension provides a wide range of code snippets for React, Redux, GraphQL, and React-Native development. It includes snippets for everything from creating functional and class components to Redux actions and reducers.

Installation

Paste the following command and press Enter:

ext install dsznajder.es7-react-js-snippets

Options

From version 4 extension provides options to customize the behavior of the snippets:

Option	Description
languageScopes	list of supported languages / files recognition
prettierEnabled	determines if snippets should be parsed with project prettier config
importReactOnTop	If disabled, snippets won't contain import React on top. React 17+ support
typescript	adds additional typescript snippets

Letast Version Download {click download}

3. Prettier - Code formatter: This extension automatically formats your code to ensure consistent styling and readability. It supports multiple languages, including React, and can be customized to fit your specific formatting preferences.

Installation

Install through VS Code extensions. Search for Prettier - Code formatter

Visual Studio Code Market Place: Prettier - Code formatter

Can also be installed in VS Code: Launch VS Code Quick Open (Ctrl+P), paste the following command, and press enter.

ext install esbenp.prettier-vscode

Default Formatter

To ensure that this extension is used over other extensions you may have installed, be sure to set it as the default formatter in your VS Code settings. This setting can be set for all languages or by a specific language.

{
  "editor.defaultFormatter": "esbenp.prettier-vscode",
  "[javascript]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
  }
}

If you want to disable Prettier on a particular language you can either create a .prettierignore file or you can use VS Code's editor.defaultFormatter settings.

The following will use Prettier for all languages except Javascript.

{
  "editor.defaultFormatter": "esbenp.prettier-vscode",
  "[javascript]": {
    "editor.defaultFormatter": "<another formatter>"
  }
}

The following will use Prettier for only Javascript.

{
  "editor.defaultFormatter": "<another formatter>",
  "[javascript]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
  }
}

Additionally, you can disable format on save for specific languages if you don't want them to be automatically formatted.

{
  "[javascript]": {
    "editor.formatOnSave": false
  }
}

Prettier Resolution

This extension will use prettier from your project's local dependencies (recommended). When the prettier.resolveGlobalModules is set to true the extension can also attempt to resolve global modules. Should prettier not be installed locally with your project's dependencies or globally on the machine, the version of prettier that is bundled with the extension will be used.

To install prettier in your project and pin its version as recommended, run:

npm install prettier -D --save-exact

NOTE: You will be prompted to confirm that you want the extension to load a Prettier module. This is done to ensure that you are not loading a module or script that is not trusted.

Plugins

This extension supports Prettier plugins when you are using a locally or globally resolved version of prettier. If you have Prettier and a plugin registered in your package.json, this extension will attempt to register the language and provide automatic code formatting for the built-in and plugin languages.

Configuration

There are multiple options for configuring Prettier with this extension. You can use VS Code settings, prettier configuration files, or an .editorconfig file. The VS Code settings are meant to be used as a fallback and are generally intended only for use on non-project files. It is recommended that you always include a prettier configuration file in your project specifying all settings for your project. This will ensure that no matter how you run prettier - from this extension, from the CLI, or from another IDE with Prettier, the same settings will get applied.

Using Prettier Configuration files to set formatting options is the recommended approach. Options are searched recursively down from the file being formatted so if you want to apply prettier settings to your entire project simply set a configuration in the root. Settings can also be configured through VS Code - however, these settings will only apply while running the extension, not when running prettier through the command line.

Configuring Default Options

Some users may not wish to create a new Prettier config for every project or use the VS Code settings. In order to set a default configuration, set prettier.configPath. However, be careful, if this is set this value will always be used and local configuration files will be ignored.

Visual Studio Code Settings

You can use VS Code settings to configure prettier. Settings will be read from (listed by priority):

1. Prettier configuration file
2. .editorconfig
3. Visual Studio Code Settings (Ignored if any other configuration is present)

NOTE: If any local configuration file is present (i.e. .prettierrc) the VS Code settings will NOT be used.

 Letast Version Download {click download}

4. ESLint: This extension provides code linting for JavaScript, including React. It helps ensure your code follows best practices, catches common mistakes, and improves overall code quality.

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 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 a .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. If you have installed ESLint globally (see above) then run eslint --init in a terminal. If you have installed ESLint locally then run .\node_modules\.bin\eslint --init under Windows and ./node_modules/.bin/eslint --init under Linux and Mac.

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 major, minor or patch version numbers indicate an insider or pre-release. So versions 2.2.3, 2.2.5, 2.3.1 and 3.0.0 will all be pre-release versions. 2.2.10, 2.4.10 and 4.0.0 will all be regular release versions.

Version 2.4.0 (same as 2.3.5 - Pre-release)

• added settings options to control the time budget for validation and fix on save before a warning or error is raised. The settings are eslint.timeBudget.onValidation and eslint.timeBudget.onFixes
• make server untitled agnostic
• the extension uses now VS Code's language status indicator
• the language status indicator now informs about long linting or fix on save times.
• the setting eslint.alwaysShowStatus got removed since the status is now shown as a language status indicator.
• support for flat config files
• support for single problem underline.
• various bug fixes

Version 2.3.5 - Pre-release

• added settings options to control the time budget for validation and fix on save before a warning or error is raised. The settings are eslint.timeBudget.onValidation and eslint.timeBudget.onFixes

Version 2.3.3 - Pre-release

• make server untitled agnostic

Version 2.3.1 - Pre-release (internal only)

• the extension uses now VS Code's language status indicator
• the language status indicator now informs about long linting or fix on save times.
• the setting eslint.alwaysShowStatus got removed since the status is now shown as a language status indicator.

Version 2.3.0 - Pre-release

• support for flat config files
• support for single problem underline.
• various bug fixes

Version 2.2.6 (same as 2.2.5 Pre-release)

• added support for validating single notebook document cells if the language is supported by ESLint
• various bug fixes

Version 2.2.5 - Pre-release

• added support for validating single notebook document cells if the language is supported by ESLint
• various bug fixes

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:

• no modal dialog is shown when the ESLint extension tries to load an ESLint library for the first time and an approval is necessary. Instead the ESLint status bar item changes to  indicating that the execution is currently block.
• if the active text editor content would be validated using ESLint, a problem at the top of the file is shown in addition.

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

• clicking on the status bar icon
• using the quick fix for the corresponding ESLint problem
• executing the command ESLint: Manage Library Execution from the command palette

All gestures will open the following dialog:

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

• Allow will prefix the status bar item with a check mark.
• Allow Everywhere will prefix the status bar item with a double check mark.
• Deny and Disable will prefix the status bar item with a blocked sign.

You can manage our decisions using the following commands:

• ESLint: Manage Library Execution will reopen above dialog
• ESLint: Reset Library Decisions lets you reset previous decisions who have made.

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:

• Improved TypeScript detection - As soon as TypeScript is correctly configured inside ESLint, you no longer need additional configuration through VS Code's eslint.validate setting. The same is true for HTML and Vue.js files.
• Glob working directory support - Projects that have a complex folder structure and need to customize the working directories via eslint.workingDirectories can now use glob patterns instead of listing every project folder. For example, { "pattern": "code-*" } will match all project folders starting with code-. In addition, the extension now changes the working directory by default. You can disable this feature with the new !cwd property.
• Formatter support: ESLint can now be used as a formatter. To enable this feature use the eslint.format.enable setting.
• Improved Auto Fix on Save - Auto Fix on Save is now part of VS Code's Code Action on Save infrastructure and computes all possible fixes in one round. It is customized via the editor.codeActionsOnSave setting. The setting supports the ESLint specific property source.fixAll.eslint. The extension also respects the generic property source.fixAll.

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

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

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

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

You can also selectively disable ESLint via:

    "editor.codeActionsOnSave": {
        "source.fixAll": true,
        "source.fixAll.eslint": false
    }

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:

• eslint.enable: enable/disable ESLint for the workspace folder. Is enabled by default.

• 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.enable: whether the extension contributes a lint task to lint a whole workspace folder.

• eslint.lintTask.options: Command line options applied when running the task for linting the whole workspace (https://eslint.org/docs/user-guide/command-line-interface). An example to point to a custom .eslintrc.json file and a custom .eslintignore is:

  {
    "eslint.lintTask.options": "-c C:/mydirectory/.eslintrc.json --ignore-path C:/mydirectory/.eslintignore ."
  }
  

• eslint.packageManager: controls 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.options": { "overrideConfigFile": "C:/mydirectory/.eslintrc.json" }
  }
  

  An example to point to a custom .eslintrc.json file using the old CLIEngine API is:

  {
    "eslint.options": { "configFile": "C:/mydirectory/.eslintrc.json" }
  }
  

• eslint.useESLintClass (@since 2.2.0) - whether to use the ESLint class API even if the CLIEngine API is present. The setting is only honor when using ESLint version 7.x.

• eslint.run - run the linter onSave or onType, default is onType.

• eslint.quiet - ignore warnings.

• eslint.runtime - use this setting to set the path of the node runtime to run ESLint under. Use "node" if you want to use your default system version of node.

• eslint.execArgv - use this setting to pass additional arguments to the node runtime like --max_old_space_size=4096

• eslint.nodeEnv - use this setting if an ESLint plugin or configuration needs process.env.NODE_ENV to be defined.

• eslint.nodePath - use this setting if an installed ESLint package can't be detected, for example /myGlobalNodePackages/node_modules.

• 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:

  • [{ "mode": "location" }] (@since 2.0.0): instructs ESLint to uses the workspace folder location or the file location (if no workspace folder is open) as the working directory. This is the default and is the same strategy as used in older versions of the ESLint extension (1.9.x versions).
  • [{ "mode": "auto" }] (@since 2.0.0): instructs ESLint to infer a working directory based on the location of package.json, .eslintignore and .eslintrc* files. This might work in many cases but can lead to unexpected results as well.
  • string[]: an array of working directories to use. Consider the following directory layout:

    root/
      client/
        .eslintrc.json
        client.js
      server/
        .eslintignore
        .eslintrc.json
        server.js
    

    Then using the setting:

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

    will validate files inside the server directory with the server directory as the current eslint working directory. Same for files in the client directory. The ESLint extension will also change the process's working directory to the provided directories. If this is not wanted a literal with the !cwd property can be used (e.g. { "directory": "./client", "!cwd": true }). This will use the client directory as the ESLint working directory but will not change the process`s working directory.
  • [{ "pattern": glob pattern }] (@since 2.0.0): Allows to specify a pattern to detect the working directory. This is basically a short cut for listing every directory. If you have a mono repository with all your projects being below a packages folder you can use { "pattern": "./packages/*/" } to make all these folders working directories.

• eslint.codeAction.disableRuleComment - object with properties:

  • enable - show disable lint rule in the quick fix menu. true by default.
  • location - choose to either add the eslint-disable comment on the separateLine or sameLine. separateLine is the default. Example:

    { "enable": true, "location": "sameLine" }
    

• eslint.codeAction.showDocumentation - object with properties:

  • enable - show open lint rule documentation web page in the quick fix menu. true by default.

• eslint.codeActionsOnSave.mode (@since 2.0.12) - controls which problems are fix when running code actions on save.

  • all: fixes all possible problems by revalidating the file's content. This executes the same code path as running eslint with the --fix option in the terminal and therefore can take some time. This is the default value.
  • problems: fixes only the currently known fixable problems as long as their textual edits are non-overlapping. This mode is a lot faster but very likely only fixes parts of the problems.

  Please note that if eslint.codeActionsOnSave.mode is set to problems, the eslint.codeActionsOnSave.rules is ignored.

• 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.codeActionsOnSave.mode has a different value than problems
  • the ESLint version used is either version 8 or higher or the version is 7.x and the setting eslint.useESLintClass is set to true (version >= 8 || (version == 7.x && eslint.useESLintClass)).

  In this example only semicolon related rules are considered:

  "eslint.codeActionsOnSave.rules": [
    "*semi*"
  ]
  

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

  "eslint.codeActionsOnSave.rules": [
    "!@typescript-eslint/*",
    "*"
  ]
  

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

  "eslint.codeActionsOnSave.rules": [
      "@typescript-eslint/semi",
      "@typescript-eslint/indent",
      "!@typescript-eslint/*",
      "*"
  ]
  

• 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 two 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

  In this example, all rules are overridden to warnings:

  "eslint.rules.customizations": [
    { "rule": "*", "severity": "warn" }
  ]
  

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

  "eslint.rules.customizations": [
    { "rule": "no-*", "severity": "info" },
    { "rule": "!no-*", "severity": "downgrade" },
    { "rule": "radix", "severity": "default" }
  ]
  

• 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:

  "[html]": {
    "editor.codeActionsOnSave": {
      "source.fixAll.eslint": false
    }
  }
  

  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.

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.

Letast Version Download {click download}

4. Debugger for Chrome: This extension allows you to debug your React applications using the Chrome browser's built-in debugger. It provides a powerful set of debugging tools and helps you quickly identify and fix issues in your code.

:rotating_light: Important

This extension has been deprecated as Visual Studio Code now has a bundled JavaScript Debugger that covers the same functionality. It is a debugger that debugs Node.js, Chrome, Edge, WebView2, VS Code extensions, and more. You can safely un-install this extension and you will still be able to have the functionality you need.

Please file any issues you encounter in that repository.

A VS Code extension to debug your JavaScript code in the Google Chrome browser, or other targets that support the Chrome DevTools Protocol.

Supported features

• Setting breakpoints, including in source files when source maps are enabled
• Stepping, including with the buttons on the Chrome page
• The Locals pane
• Debugging eval scripts, script tags, and scripts that are added dynamically
• Watches
• Console

Unsupported scenarios

• Debugging web workers
• Debugging Chrome extensions
• Any features that aren't script debugging

Getting Started

1. Install the extension
2. Open the folder containing the project you want to work on.

Using the debugger

When your launch config is set up, you can debug your project. Pick a launch config from the dropdown on the Debug pane in Code. Press the play button or F5 to start.

Configuration

The extension operates in two modes - it can launch an instance of Chrome navigated to your app, or it can attach to a running instance of Chrome. Both modes requires you to be serving your web application from local web server, which is started from either a VS Code task or from your command-line. Using the url parameter you simply tell VS Code which URL to either open or launch in Chrome.

Just like when using the Node debugger, you configure these modes with a .vscode/launch.json file in the root directory of your project. You can create this file manually, or Code will create one for you if you try to run your project, and it doesn't exist yet.

Tip: See recipes for debugging different frameworks here: https://github.com/Microsoft/vscode-recipes

Launch

Two example launch.json configs with "request": "launch". You must specify either file or url to launch Chrome against a local file or a url. If you use a url, set webRoot to the directory that files are served from. This can be either an absolute path or a path using ${workspaceFolder} (the folder open in Code). webRoot is used to resolve urls (like "http://localhost/app.js") to a file on disk (like /Users/me/project/app.js), so be careful that it's set correctly.

{
    "version": "0.1.0",
    "configurations": [
        {
            "name": "Launch localhost",
            "type": "chrome",
            "request": "launch",
            "url": "http://localhost/mypage.html",
            "webRoot": "${workspaceFolder}/wwwroot"
        },
        {
            "name": "Launch index.html",
            "type": "chrome",
            "request": "launch",
            "file": "${workspaceFolder}/index.html"
        },
    ]
}

If you want to use a different installation of Chrome, you can also set the runtimeExecutable field with a path to the Chrome app.

Attach

With "request": "attach", you must launch Chrome with remote debugging enabled in order for the extension to attach to it. Here's how to do that:

Windows

• Right click the Chrome shortcut, and select properties
• In the "target" field, append --remote-debugging-port=9222
• Or in a command prompt, execute <path to chrome>/chrome.exe --remote-debugging-port=9222

macOS

• In a terminal, execute /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --remote-debugging-port=9222

Linux

• In a terminal, launch google-chrome --remote-debugging-port=9222

If you have another instance of Chrome running and don't want to restart it, you can run the new instance under a separate user profile with the --user-data-dir option. Example: --user-data-dir=/tmp/chrome-debug. This is the same as using the userDataDir option in a launch-type config.

Launch Chrome and navigate to your page.

An example launch.json file for an "attach" config.

{
    "version": "0.1.0",
    "configurations": [
        {
            "name": "Attach to url with files served from ./out",
            "type": "chrome",
            "request": "attach",
            "port": 9222,
            "url": "<url of the open browser tab to connect to>",
            "webRoot": "${workspaceFolder}/out"
        }
    ]
}

Chrome user profile note (Cannot connect to the target: connect ECONNREFUSED)

Normally, if Chrome is already running when you start debugging with a launch config, then the new instance won't start in remote debugging mode. So by default, the extension launches Chrome with a separate user profile in a temp folder. Use the userDataDir launch config field to override or disable this. If you are using the runtimeExecutable field, this isn't enabled by default, but you can forcibly enable it with "userDataDir": true.

If you are using an attach config, make sure you close other running instances of Chrome before launching a new one with --remote-debugging-port. Or, use a new profile with the --user-data-dir flag yourself.

For other troubleshooting tips for this error, see below.

Errors from chrome-error://chromewebdata

If you see errors with a location like chrome-error://chromewebdata/ in the error stack, these errors are not from the extension or from your app - they are usually a sign that Chrome was not able to load your app.

When you see these errors, first check whether Chrome was able to load your app. Does Chrome say "This site can't be reached" or something similar? You must start your own server to run your app. Double-check that your server is running, and that the url and port are configured correctly.

Other targets

You can also theoretically attach to other targets that support the same Chrome Debugging protocol, such as Electron or Cordova. These aren't officially supported, but should work with basically the same steps. You can use a launch config by setting "runtimeExecutable" to a program or script to launch, or an attach config to attach to a process that's already running. If Code can't find the target, you can always verify that it is actually available by navigating to http://localhost:<port>/json in a browser. If you get a response with a bunch of JSON, and can find your target page in that JSON, then the target should be available to this extension.

Examples

See our wiki page for some configured example apps: Examples

Other optional launch config fields

• trace: When true, the adapter logs its own diagnostic info to a file. The file path will be printed in the Debug Console. This is often useful info to include when filing an issue on GitHub. If you set it to "verbose", it will also log to the console.
• runtimeExecutable: Workspace relative or absolute path to the runtime executable to be used. If not specified, Chrome will be used from the default install location.
• runtimeArgs: Optional arguments passed to the runtime executable.
• env: Optional dictionary of environment key/value pairs.
• cwd: Optional working directory for the runtime executable.
• userDataDir: Normally, if Chrome is already running when you start debugging with a launch config, then the new instance won't start in remote debugging mode. So by default, the extension launches Chrome with a separate user profile in a temp folder. Use this option to set a different path to use, or set to false to launch with your default user profile.
• url: On a 'launch' config, it will launch Chrome at this URL.
• urlFilter: On an 'attach' config, or a 'launch' config with no 'url' set, search for a page with this url and attach to it. It can also contain wildcards, for example, "localhost:*/app" will match either "http://localhost:123/app" or "http://localhost:456/app", but not "https://stackoverflow.com".
• targetTypes: On an 'attach' config, or a 'launch' config with no 'url' set, set a list of acceptable target types from the default ["page"]. For example, if you are attaching to an Electron app, you might want to set this to ["page", "webview"]. A value of null disables filtering by target type.
• sourceMaps: By default, the adapter will use sourcemaps and your original sources whenever possible. You can disable this by setting sourceMaps to false.
• pathMapping: This property takes a mapping of URL paths to local paths, to give you more flexibility in how URLs are resolved to local files. "webRoot": "${workspaceFolder}" is just shorthand for a pathMapping like { "/": "${workspaceFolder}" }.
• smartStep: Automatically steps over code that doesn't map to source files. Especially useful for debugging with async/await.
• disableNetworkCache: If false, the network cache will be NOT disabled. It is disabled by default.
• showAsyncStacks: If true, callstacks across async calls (like setTimeout, fetch, resolved Promises, etc) will be shown.
• breakOnLoad: Experimental. If true, the debug adapter will attempt to set breakpoints in scripts before they are loaded, so it can hit breakpoints at the beginnings of those scripts. Has a perf impact.
• breakOnLoadStrategy: The strategy used for breakOnLoad. Options are "Instrument" or "Regex". Instrument "[tells] Chrome to pause as each script is loaded, resolving sourcemaps and setting breakpoints" Regex "[s]ets breakpoints optimistically in files with the same name as the file in which the breakpoint is set."

Skip files / Blackboxing / Ignore files

You can use the skipFiles property to ignore/blackbox specific files while debugging. For example, if you set "skipFiles": ["jquery.js"], then you will skip any file named 'jquery.js' when stepping through your code. You also won't break on exceptions thrown from 'jquery.js'. This works the same as "blackboxing scripts" in Chrome DevTools.

The supported formats are:

• The name of a file (like jquery.js)
• The name of a folder, under which to skip all scripts (like node_modules)
• A path glob, to skip all scripts that match (like node_modules/react/*.min.js)