prettier/prettier-vscode

Settings in VSCode's `settings.json` didn't work when there is a `.editorconfig` in the project

Henry-WHY opened this issue · 7 comments

Environments:

  • Prettier - Code formatter Version: 3.8.0
  • VSCode Version: 1.40.1
  • Operating System: win10

Steps to reproduce:

Settings should be read from

  1. Prettier configuration file
  2. .editorconfig
  3. Visual Studio Code Settings

But as long as there's a .editorconfig in the project without .prettierrc, Settings which have been written in the VSCode's settings.json are no longer valid, even if they are not mentioned in the .editorconfig

Expected behavior:

Read the settings which are not mentioned in the .editorconfig from VSCode's settings.json

Actual behavior:

Read the settings which are not mentioned in the .editorconfig from prettier's default settings

This is by design. The VSCode settings are fallback only. If prettier finds a config file (editorconfig or prettier config) then only those config will be used. The recommendation is to set a prettier configuration file for the project.

Do I have to set a prettier configuration for every project just for no semicolon ?

Yeah, that's what you would have to do. I think this is the correct behavior because you also should be able to run prettier in a project through the CLI and if we included VS Code settings running through the vscode extension and the cli would produce different results. The VS Code settings are really only intended to be used in non-projects. Like if you open a JSON file and want to format it. The recommendation is to ALWAYS include a .prettierrc file with all settings in every project that uses prettier.

@ntotten Is it really smart though?

For example I see here editorconfig/editorconfig#331
the possibility of removing trailing semi colons are not possible and having .editorconfig file is deemed a good practice in some project.

Achieing all options like prettier.semi not possible if that file exist :/

Also Angular creates .editorconfig by default for new projects.

I'm not a fan of this change because, for all of my Angular projects that had my linting + formatting working a few days ago, I now need to make changes for all of them to be usable.

This seems like a rather large update to prettier that suddenly had me not being able to write code as my formatting and linting were all messed up which muddies git commits with "changes" just due to format.

Instead of dealing with this, I just reverted back to 3.7.0 and everything worked as expected.

Similarly, I mostly use prettier for formatting the README markdown in my projects. To enable line wrapping I enable a single option "prettier.proseWrap": "always", so that I can use prettier to correctly wrap markdown text in my README.

This change requires me to add a prettierrc config file to every one of my projects just to be able to have prettier wrap long lines in my README which is rather annoying.

I can understand disabling the VSCode settings when a .prettierrc file is found but please don't disable VSCode options when a .editorconfig file is found.

Another option is to merge VSCode prettier options that cannot be expressed in editorconfig instead of discarding them.

EDIT: I found the option to disable use of .editorconfig but would still like the prettier specific VSCode options to be merged with the editorconfig inferred options if possible.

I know some people are passionate about this behavior, but there are 500k daily users of this extension and for the vast majority, this behavior is correct.

I might consider adding a setting to merge the editor config and VSCode settings, but that will require changes to prettier itself as right now there is no way to know where prettier resolved the setting from.

To be very honest though, I don’t really put much weight in the argument that you don’t want to add a prettier config file to your project because 1) it takes 15 seconds and 2) it is a best practice when using prettier.

As I explained before, merging by default has a lot of undesirable consequences that are far more important than a simple convenience of not adding a config file.