search

prettier / prettier-vscode

Visual Studio Code extension for Prettier
https://marketplace.visualstudio.com/items?itemName=esbenp.prettier-vscode
MIT License
5.15k stars 456 forks source link

VS Code's indentation settings aren't overridden #1859

Open thorn0 opened 3 years ago

thorn0 commented 3 years ago

Summary

This was discussed in https://github.com/prettier/prettier-vscode/issues/1515#issuecomment-801884216 and turned out to be a separate issue.

Steps To Reproduce:

  1. create an empty directory
  2. create .prettierrc in it, with this content: {"tabWidth": 2}
  3. create an empty index.js

Expected result

When I open the empty file,

Actual result

When I opened this directory in VS Code and opened index.js, I saw "Spaces: 4" in the status bar. Pressing the Tab key inserted 4 spaces. After adding some code with indentation to this file, formatting it with Prettier (it got correctly indented with 2 spaces), closing, and opening the file again, VS Code's autodetection worked (as editor.detectIndentation is true by default) and this time correctly showed "Spaces: 2" in the status bar, the Tab key started to work as expected too.

Additional information

For my tests, I disabled other extensions that could affect this. In particular, EditorConfig and ESLint.

The EditorConfig extension doesn't have this problem. It changes the behavior of VS Code even in empty files.

https://github.com/prettier/prettier-vscode/issues/1327 might be related (the extension seems to fail to override VS Code's behavior in that case too).

VS Code Version:

1.54.3

Prettier Extension Version:

6.3.1

OS and version:

Windows 10 x64 20H2

ntotten commented 3 years ago

I'm not sure we can change that. AFAIK there isn't an API to change that in the editor besides writing the setting, but I am not comfortable overwriting settings on behalf of a user.

OliverJAsh commented 3 years ago

Considering this is the behaviour out of the box, it could be quite confusing to new users.

The steps to reproduce can be simplified even more:

  1. Create a new directory and open VS Code with default settings and no extensions to simulate a new user: code --user-data-dir data --extensions-dir data-extensions .
  2. Install the Prettier extension
  3. Create a JS file

To fix this I think the Prettier extension would need to override the editor.tabSize setting. I think the user would always want the editor setting to match their formatter.

phoenixeliot commented 3 years ago

I'm not sure we can change that. AFAIK there isn't an API to change that in the editor besides writing the setting, but I am not comfortable overwriting settings on behalf of a user.

I think this could potentially be solved with a little alert bubble, asking the user if they want to set their workspace tab setting to match their prettier config, if the extension detects that there is a prettier config and that it doesn't match the setting

long76 commented 1 year ago

up vote

danielniccoli commented 1 year ago

I just ran into the same problem and it took me a long time to find this issue.

I'm not sure we can change that. AFAIK there isn't an API to change that in the editor besides writing the setting, but I am not comfortable overwriting settings on behalf of a user.

So, do i understand correctly that in VS Code the tabWidth setting in .prettierrc has no effect and the VS Code config takes precedence? And you are saying that you are not comfortable overriding the VS Code setting with the .prettierrc setting?

What confused me was the following: https://github.com/prettier/prettier-vscode/blob/affc1e5b44fc6d0d9d4a957e327e0da57045bf56/README.md?plain=1#L222

My understanding of that sentence is that the precedence is in the following order:

  1. tabWidth in .prettierrc
  2. prettier.tabWidth in .vscode/settings.json
  3. editor.tabSize in .vscode/settings.json

This is very confusing.

If you set only 1. and neither of 2. and 3. then the behaviour seems completely arbitrary. Files that already have a tabSize of 4 stay like that. Files with a tabsize of 2 also stay like that. And sometimes new files get formatted with either one.

Maybe it would help clarifying the current behaviour? It definitely would help me understand, what I must configure to reliably have a tab size of 4 spaces, that also gets applied with certainty when I paste code with a tabsize of 2.