# The EditorConfig extension makes VS Code obey your .editorconfig file

> editorconfig-vscode is the official EditorConfig extension for Visual Studio Code, and it works by resolving the configuration for each file you open and overriding your user and workspace settings with it. It supports seven properties, three of which only take effect on save, and it ships one documented bug that will bite teams using trim_trailing_whitespace.

**editorconfig/editorconfig-vscode** — EditorConfig extension for Visual Studio Code

- Repository: https://github.com/editorconfig/editorconfig-vscode
- Website: http://editorconfig.org/
- Stars: 1,374 · Forks: 142
- Language: TypeScript
- License: MIT
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/editorconfig-editorconfig-vscode

## One extension, and the core it delegates to

editorconfig-vscode is the EditorConfig extension for Visual Studio Code, and the readme is careful about what that means. This repository is specific to the EditorConfig Extension for Visual Studio Code, and internally it uses the editorconfig npm package, which the documentation describes as one of a few EditorConfig cores available.

That distinction matters if you are evaluating EditorConfig itself. The extension is not an implementation of the format, it is a bridge between one editor and an existing implementation. The same file will therefore behave the same way in an editor that uses a different core, which is the point of a format with several cores.

The extension is published by the EditorConfig publisher, with the display name EditorConfig, and the marketplace identifier is editorconfig.editorconfig. The readme notes that when identifying an extension you should provide the full publisher.extension form, since a bare name is ambiguous once a workspace has several extensions installed.

It is MIT licensed, with the licence file named LICENSE.md and a ThirdPartyNotices.txt alongside it, and the project is the official one, hosted at the editorconfig organisation with a Gitter chat and a GitHub Actions workflow for tests.

## Installation is a marketplace identifier and nothing else

The installation section is deliberately short. You identify the extension by its full name in the form publisher.extension, which for this one is editorconfig.editorconfig, and you install it the way you install any other VS Code extension, with the marketplace documentation covering the various ways of doing that.

The significant part of the installation story is what is not required. The readme states that no additional or vscode-specific files are required, which is the argument for EditorConfig over a per-editor configuration file. A project that already has .editorconfig files does not need to add a VS Code settings block to every repository, and the extension does not need a configuration file of its own.

There is a caveat, and it is the kind that surprises people. As with any EditorConfig plugin, if root=true is not specified, EditorConfig will continue to look for an .editorconfig file outside the project. The readme links to the file location rules on the EditorConfig site for the details. In a monorepo or a home directory that contains its own .editorconfig, that behaviour means settings can arrive from a parent directory you did not know was participating, so the fix is a root=true in the top level file of the repository.

The extension is also multi-root ready, which the package keywords say, so a workspace with several folders resolves each file against its own project.

## Eight properties, and three of them only land on save

The supported property list is short and specific, and it is a subset of what the EditorConfig format allows.

The first group is indentation. indent_style, indent_size and tab_width are all supported. The second group is line endings and whitespace, with end_of_line, insert_final_newline and trim_trailing_whitespace. The third is charset. And the readme marks the three formatting properties with the note that some settings can only be applied on file save, as indicated above.

That marker is the important detail. The extension applies the configuration to the editor session, but end_of_line, insert_final_newline and trim_trailing_whitespace are actions that VS Code performs when it writes a file. There is no way to apply them to the buffer you are looking at, so they take effect on the next save rather than immediately.

For a team that expects a file to look right the moment it is opened, that is a surprise. A file with trailing whitespace stays as it is until somebody saves it, and an editor that never saves leaves the file alone. It also means the extension is not a formatter. Nothing is rewritten on the fly, and the extension will not touch a file you have not saved.

## Resolution happens per file, on activation

The how it works section describes the activation model, and it explains why an EditorConfig extension feels instant without being fast.

The extension is activated whenever you open a new text editor, switch tabs into an existing one, or focus into the editor you already have open. When activated, it uses the editorconfig package to resolve the configuration for that particular file and applies any relevant editor settings.

So the unit of work is a single file. The extension asks the core for the configuration that applies to the file in front of you, which means the core walks the directory tree from the file upwards looking for .editorconfig files and merges them according to the format's rules. The result is then translated into VS Code settings and applied.

The package manifest shows the activation configuration, and it is not the usual onLanguage or onCommand pattern.

```json
"activationEvents": [
  "onStartupFinished"
],
"main": "./out/editorConfigMain.js",
"engines": {
  "vscode": "^1.100.0"
}
```

The activation event is onStartupFinished, so the extension is loaded once when the window is ready, and the per-file work happens after that. The engines field sets the floor at VS Code 1.100.0, which is the compatibility constraint to check before installing into an older editor.

## Generating an .editorconfig from the settings you already have

The extension can create an .editorconfig file for you, and the mechanism is worth knowing about because it is how most projects end up with one.

In the Explorer sidebar you right-click the folder where you want the file and select Generate .editorconfig from the context menu. The readme says a new file can be created that way, and the package manifest shows the command it registers, EditorConfig.generate, with the title Generate .editorconfig.

Three settings control the behaviour, and their defaults decide whether the extension is helpful or noisy. editorconfig.generateAuto is a boolean defaulting to true, and its description says it automatically generates an .editorconfig file according to your current editor settings. editorconfig.template is a string defaulting to default, and it is used for each newly generated file when generateAuto is false. editorconfig.showMenuEntry is a boolean defaulting to true, which shows the Generate .editorconfig entry in the context menu of the Explorer view.

The generateAuto default is the interesting one. With it on, a .editorconfig file appears based on whatever your current editor settings happen to be, which is a reasonable way to capture a convention that already exists in your head, and a reasonable way to accidentally enshrine a setting you never meant to standardise. Turning it off and using a template file gives you something reviewable instead.

## The trimTrailingWhitespace bug that is still open

The readme has a known issues section with one entry, and it is specific enough to be worth planning around.

trim_trailing_whitespace = false is not applied when the user or workspace setting of files.trimTrailingWhitespace is set to true. The entry links to issue 153 in the repository.

The mechanism is a conflict between two layers. The .editorconfig file asks for trailing whitespace to be kept, and your VS Code user or workspace settings ask for it to be removed on save. The extension's intent is to override user and workspace settings with what .editorconfig says, but in this one case the user setting wins.

Why it matters is that the two configurations can disagree silently. A developer whose personal settings trim trailing whitespace will, on save, strip whitespace that the project explicitly asked to keep, and the resulting diff looks like an unrelated change to everyone else. The setting that is supposed to be the source of truth is the one that is being ignored, and it only shows up on save, which is the same timing as the three save-time properties.

The workaround is to align the user setting with the file, which in practice means turning files.trimTrailingWhitespace off for that workspace.

## A small repository with a recent release history

The repository is not archived, and the last push was on 2026-04-23, which is a little under six months before this review. The releases are on the 0.18 line, with v0.18.2 on 2026-04-08, v0.18.1 on 2026-01-22 and v0.18.0 on 2026-01-21.

The project layout is the ordinary shape of a VS Code extension written in TypeScript. There is a src/ directory for the extension code, a syntaxes/ directory and an editorconfig.language-configuration.json, both of which point to the extension doing more than reading settings: it contributes language behaviour, not just configuration. The build output is in out/, referenced by the main and types fields in the manifest.

The supporting files are the ones you would expect from a project that cares about consistency. There is an.editorconfig at the root, so the project uses the format it ships support for, an.eslintrc.json with an.eslintignore, a.prettierignore, a.vscodeignore that controls what is excluded from the packaged extension. DEVELOPER.md covers working on the extension and CHANGELOG.md records the release history.

The licence is MIT in a LICENSE.md file, and the ThirdPartyNotices.txt at the root is there because the extension bundles or depends on code with its own terms, which is the case for anything that ships the editorconfig core inside the packaged extension.

## Conclusion

Adopt editorconfig-vscode when a repository already carries .editorconfig files and you want the editor to honour them instead of fighting the formatter, since the extension is maintained by the EditorConfig project itself and needs no extra configuration files. Do not adopt it as a formatter, because it applies settings rather than rewriting files on demand. Verify first that your .editorconfig sets root=true, since without it EditorConfig keeps looking outside the project, and check the known issue about files.trimTrailingWhitespace, because a user setting of true will override trim_trailing_whitespace = false.

## FAQ

### How do I install the EditorConfig extension for VS Code?

Install it from the extension marketplace using the full identifier editorconfig.editorconfig, in the publisher.extension form. The README points to the Visual Studio Code extension gallery documentation for the different installation methods.

### Which .editorconfig properties does editorconfig-vscode support?

indent_style, indent_size, tab_width, end_of_line, insert_final_newline, trim_trailing_whitespace and charset. The readme notes that some settings can only be applied on file save, as indicated in the list.

### Why is my .editorconfig file ignored outside the project?

As with any EditorConfig plugin, if root=true is not specified, EditorConfig will continue to look for an .editorconfig file outside of the project. Adding root=true to the top level file stops the search at the repository root.

### How do I create a new .editorconfig file in VS Code?

Right-click the folder in the Explorer sidebar and choose Generate .editorconfig. The extension also has a generateAuto setting, on by default, which generates a file according to your current editor settings, and a template setting used when generateAuto is false.

### Does editorconfig-vscode format files as I type?

No. The extension applies the resolved configuration as editor settings when a text editor is opened or focused. end_of_line, insert_final_newline and trim_trailing_whitespace are applied on file save, so nothing is rewritten until you save.

### What known issue does the EditorConfig extension have?

trim_trailing_whitespace = false is not applied when the user or workspace setting of files.trimTrailingWhitespace is set to true, which is tracked as issue 153 in the repository.

## Sources

- [editorconfig/editorconfig-vscode on GitHub](https://github.com/editorconfig/editorconfig-vscode)
- [License: MIT](https://github.com/editorconfig/editorconfig-vscode/blob/main/LICENSE)
- [Project website](http://editorconfig.org/)
- [README](https://github.com/editorconfig/editorconfig-vscode/blob/main/README.md)
- [Releases](https://github.com/editorconfig/editorconfig-vscode/releases)

---

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