# microsoft/vscode-eslint: ESLint diagnostics and fixes in VS Code

> The vscode-eslint extension connects VS Code to the ESLint installation associated with an opened workspace. It is best suited to JavaScript, TypeScript, Vue, Astro, MDX, JSON, and CSS projects that already run ESLint, with important limits around workspace trust, virtual workspaces, and legacy ESLint versions.

**microsoft/vscode-eslint** — VSCode extension to integrate eslint into VSCode

- Repository: https://github.com/microsoft/vscode-eslint
- Stars: 1,964 · Forks: 387
- Language: TypeScript
- License: MIT
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/microsoft-vscode-eslint

## Why vscode-eslint fits a repository-based ESLint workflow

vscode-eslint solves the gap between editing a file in VS Code and checking that file with the ESLint installation that the project actually uses. It is designed for developers who want lint problems and fixes to appear in the editor without maintaining a second lint configuration for local development. The extension does not bundle ESLint as the primary source of project rules. According to the README, it uses the ESLint library installed in the opened workspace folder, then looks for a global installation if the folder does not provide one. That choice matters in monorepos, packages with different ESLint versions, and repositories that rely on local configuration.

The intended audience is broader than JavaScript projects because the extension can validate configured language identifiers such as JavaScript, TypeScript, and Vue. The release notes also mention probing support for Astro, MDX, JSON, and CSS. The exact validation scope still depends on the selected languages and the extension settings. The project should therefore be treated as an editor integration for ESLint, not as a replacement for ESLint itself. A team that has no ESLint dependency and does not want to add one will not get the expected result from installing the extension alone.

## Workspace resolution, server architecture, and trust boundaries

The repository layout separates the extension into `client`, `server`, and `shared` areas, with the client entry point declared as `./client/out/extension` in `package.json`. This indicates an editor-side client and a language-server component. The README does not provide the complete request protocol, so the exact message sequence cannot be confirmed here. It does confirm that the server resolves ESLint from the opened workspace rather than assuming one editor-wide copy.

The extension activates through `onStartupFinished` and declares `workspace` as its extension kind. That means its execution is associated with a workspace context. Its manifest also says that untrusted workspaces are unsupported because the extension loads configuration files and code from the workspace and executes it. This is a deliberate security boundary, not a minor setup inconvenience. A workspace that contains executable ESLint configuration or plugins should not be opened as trusted unless the repository and its dependencies are expected to run.

The manifest also states that virtual workspaces are unsupported. A virtual workspace therefore falls outside the environment in which this extension promises to run ESLint. The extension is not a validator for remote or virtual project surfaces in its current documented configuration.

## Installing ESLint and enabling the first real check

The README recommends installing ESLint locally in the project. Local installation is preferable when the repository needs a specific version or when multiple workspaces use different ESLint configurations. The project gives equivalent commands for npm, yarn, pnpm, and bun. Choose the command that matches the package manager already recorded by the project.

For a JavaScript project using npm, the local installation command is:

```bash
npm install --save-dev eslint
```

The repository also documents these alternatives:

```bash
yarn add --dev eslint
pnpm add --save-dev eslint
bun add --dev eslint
```

After ESLint is installed, the README says that a new project may need an ESLint configuration file. For ESLint v9 and later, or v8.57 and later with flat config, the documented filenames include `eslint.config.js`, `eslint.config.mjs`, `eslint.config.cjs`, `eslint.config.ts`, and `eslint.config.mts`. The documented starter command is:

```bash
npx eslint --init
```

The README does not give a command for installing the VS Code extension itself. Install `vscode-eslint` through the VS Code extension interface, then reopen the project so the workspace ESLint installation can be found. The expected first result is an ESLint diagnostic after opening a file covered by the configured validation rules.

## Configuring validation and save-time ESLint fixes

The workspace can restrict validation to specific language identifiers. The README gives `javascript`, `typescript`, and `vue` as an example. This setting is enforced: release notes for version 3.0.11 state that when `eslint.validate` is specified, only files in that list will be validated. That behavior is comparable to supplying extensions to the ESLint command line.

A project can request ESLint's fix-all code action on save through the editor setting shown by the README:

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

The `explicit` value requests that the action run when explicitly allowed by VS Code's save-action behavior. It does not mean that every ESLint issue can be fixed automatically, and it does not guarantee that a fix is syntactically or semantically desirable. Users should review edits produced by automated fixes.

For validation, the example workspace setting is:

```json
{
  "eslint.validate": [
    "javascript",
    "typescript",
    "vue"
  ]
}
```

The setting can live in workspace settings, which is useful when a repository wants validation behavior that differs from a user's global editor configuration. The README does not document a separate setting for choosing a global ESLint binary. Instead, resolution follows the local workspace installation first and a global installation second.

## Flat config compatibility and legacy ESLint boundaries

The extension's configuration behavior depends heavily on the ESLint version found in the workspace. The README says that ESLint v9 and later use flat config by default. It also says that ESLint 8.57 and above can use flat config, while older versions use legacy `.eslintrc` files such as `.eslintrc.json` and `.eslintrc.js`.

The release notes document the `eslint.useFlatConfig` setting for the transition period. For ESLint versions from 8.57.0 up to, but not including, 9.x, the setting is honored and defaults to false. For ESLint versions from 9.0.0 up to, but not including, 10.x, it is honored and defaults to true. For ESLint 10 and later, the setting is ignored because flat config is the default and cannot be turned off. The experimental `eslint.experimental.useFlatConfig` setting is deprecated and is intended only for versions from 8.21 up to, but not including, 8.57.0.

This compatibility matrix is a useful adoption check. A project pinned to an old ESLint version may require legacy configuration, while a newer project should verify that its `eslint.config.*` file is discovered by the version installed in that workspace. The extension cannot be judged independently of the ESLint package version.

## Limitations, alternatives, maintenance, and upgrade cost

The clearest limitation is that the extension executes workspace configuration and code, which is why untrusted workspaces are unsupported. Virtual workspaces are also explicitly unsupported. In addition, `eslint.validate` can silently narrow validation to the listed languages, so a missing language entry can look like the absence of lint errors. The extension also relies on a local or global ESLint installation. A missing or incorrectly resolved package is a setup failure, not a feature of the editor integration.

A real alternative is to invoke ESLint directly from a terminal or task, using the workspace package and its configuration. That approach is better when lint results must be identical in continuous integration, when the editor environment is virtual or untrusted, or when a command-line task is the required interface. vscode-eslint is better when developers want editor diagnostics, focus-triggered revalidation, ESLint code actions, and workspace-local behavior during editing. The extension release notes also mention the command `ESLint: Revalidate all open files` and diagnostic pull behavior, which are editor workflows rather than substitutes for a build or CI lint job.

The repository is not archived, and its last push was on 2026-10-16. The package is identified as version 3.0.35, while the README lists version 3.0.34 as the latest regular release described in the release notes. Upgrade cost includes checking the ESLint version, flat config or `.eslintrc` format, validation languages, bulk suppression settings, and any plugin compatibility. The project is MIT licensed. That identifies the repository's stated license, but teams handling distribution or compliance should review the actual license files and dependencies themselves rather than treating this review as legal advice.

## Conclusion

Adopt vscode-eslint when your repository has a reproducible ESLint setup and you want diagnostics inside VS Code. Do not expect it to replace the ESLint command line, work in virtual workspaces, or operate without workspace trust. Verify first that the opened workspace exposes the intended ESLint version and configuration, then check the `eslint.validate` setting for file coverage.

## FAQ

### How do I install vscode-eslint for a VS Code project?

Install the extension through the VS Code extension interface, then install ESLint in the opened workspace. The README does not document a command-line installation step for the extension itself.

### Which ESLint version should I use with vscode-eslint?

Use the version required by the project. The README supports ESLint v8.57 and later with flat config, while ESLint v9 and later use flat config by default; older versions use legacy `.eslintrc` files.

### Why is ESLint not validating all of my files?

The `eslint.validate` setting can restrict validation to specific language identifiers. The README shows `javascript`, `typescript`, and `vue`, and the release notes state that only files in the configured list will be validated when the setting is specified.

### Can vscode-eslint run in an untrusted or virtual workspace?

No. The package manifest says that untrusted workspaces and virtual workspaces are unsupported. The extension loads workspace configuration and code, and it states that this code is executed.

## Sources

- [Issues](https://github.com/microsoft/vscode-eslint/issues)
- [License: MIT](https://github.com/microsoft/vscode-eslint/blob/main/LICENSE)
- [microsoft/vscode-eslint on GitHub](https://github.com/microsoft/vscode-eslint)
- [README](https://github.com/microsoft/vscode-eslint/blob/main/README.md)
- [Releases](https://github.com/microsoft/vscode-eslint/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/microsoft-vscode-eslint