Builtin and extensive .editorconfig support

[sandersaares]

I want VS Code to respect all the settings in a repo's .editorconfig file.

It looks like some partial support has existed in the form of an extension that has been community-maintained but the maintainer is not able to contribute to open source at present due to policy: editorconfig/editorconfig-vscode#263

The extension has 5.1 million installs, indicating strong user interest. Therefore I see this as a valuable candidate for high priority 1st party implementation by Microsoft.

[alystair]

@egamma perhaps label this for improved issue health? No update since November.

[nrayburn-tech]

@egamma any information you can share on how this issue can be resolved?

I am happy to help improve the editorconfig functionality (and have submitted some PRs recently), but the current issue regarding a maintainer for the project would probably be best handled by somebody from the vscode team.

[SamB]

This could also mitigate #65663 (about letting extensions override e.g. files.insertFinalNewline and files.trimTrailingWhitespace on a per-file basis), insofar as it would presumably solve editorconfig/editorconfig-vscode#209 and editorconfig/editorconfig-vscode#153.

That might not actually solve the issue, though: #65663 (comment) points out that, for example, eslint has also rules, specifically eol-last and no-trailing-spaces, which the core settings can interfere with: whether you fix violations manually or as part of saving, if VS Code follows that up by adding/removing forbidden/mandatory whitespace, eslint will be upset, possibly breaking the build, even in trees with no .vscode/settings.json or .editorconfig.

Conclusion: Moving to core could help EditorConfig do EditorConfig-type things better, but EditorConfig isn't the only thing that has legitimate reason to do EditorConfig-type things, so it might be better to:

1. Move maintenance back from https://github.com/editorconfig/editorconfig-vscode to https://github.com/microsoft/vscode-editorconfig
2. Start trying to hammer out API that can serve the needs of EditorConfig, https://github.com/Microsoft/vscode-eslint, etc. while being easier to use properly than to abuse. That is, fix Temporarily Set Configuration For Save Operation #65663.

[sanmai-NL]

Simply packaging the EditorConfig extension in the default install, would move this forward already. When someone adds other formatters, he can then address the advanced issues. And so can we.

[jasonwilliams]

I agree with the above, I would love to see native support for editorConfig rather than a plugin that's being half-maintained. 3.3 million installs is a lot and suggests a lot of demand for something like this.

Even having the extension move back to Microsoft would be a useful start.

[KamilaBorowska]

Additionally I would like to point out that this repository has .editorconfig file: https://github.com/microsoft/vscode/blob/main/.editorconfig

[segevfiner]

It even recommends the extension that currently has this issue 😛

[treyhunner]

I'm chiming in as a member of the EditorConfig team to say that the EditorConfig team would love to see support baked-in to VS Code.

WebStorm, Visual Studio, and PyCharm all rolled-in extensions (or rewrote them) to their core shipped editors and it helped newer folks in particular (new to coding, open source, or just the project they're now working on). Having the editor automatically adopt the preferred style for the project you're working on can reduce a lot of headache for open source contributors in particular.

I'm biased here, but the extension has over 5 million downloads and unlike other popular VS Code extensions this is both a fairly stable feature (the most recently officially-recognized EditorConfig option was added years ago) and it's a feature that's hard to know you're missing until it's too late (if you don't know what that .editorconfig file means, you don't realize you're disobeying the project's code style).

I'd love to see EditorConfig baked-in to VS Code. 👏

[romanlum]

+1