Prettier-vscode: Does not use VSCode tab/spacing settings

[JVimes]

Summary

For GraphQL, the formatter seems to indent by 2 spaces even when VSCode is configured to indent by a different number, or by tabs. This behavior may be specific to GraphQL, I don't see it with JSON.

Steps To Reproduce:

1. Open a GraphQL file, such as query.graphql:

   query {
     foo {
       bar
     }
   }
   

2. Try different indentation settings in VSCode, and run "format document" for each.

Expected result

Formatting uses VSCode's selected indentation: tabs, spaces, number of spaces.

Actual result

Indentation is always done with 2 spaces.

Additional information

VS Code Version: 1.49.0-insider

Prettier Extension Version: v5.1.3

OS and version: Version 2004 (OS Build 19041.450)

Prettier Log Output

["INFO" - 9:33:15 AM] Formatting c:\path\to\query.graphql
["INFO" - 9:33:15 AM] Using ignore file (if present) at undefined
["INFO" - 9:33:15 AM] Using bundled version of prettier.
["INFO" - 9:33:15 AM] File Info:
{
  "ignored": false,
  "inferredParser": "graphql"
}
["INFO" - 9:33:15 AM] No local configuration (i.e. .prettierrc or .editorconfig) detected, falling back to VS Code configuration
["INFO" - 9:33:15 AM] Prettier Options:
{
  "arrowParens": "always",
  "bracketSpacing": true,
  "endOfLine": "lf",
  "htmlWhitespaceSensitivity": "css",
  "insertPragma": false,
  "jsxBracketSameLine": false,
  "jsxSingleQuote": false,
  "printWidth": 80,
  "proseWrap": "preserve",
  "quoteProps": "as-needed",
  "requirePragma": false,
  "semi": true,
  "singleQuote": false,
  "tabWidth": 2,
  "trailingComma": "es5",
  "useTabs": false,
  "vueIndentScriptAndStyle": false,
  "filepath": "c:\\path\\to\\query.graphql",
  "parser": "graphql"
}
["INFO" - 9:33:15 AM] Formatting completed in 33.6648ms.

[ntotten]

That setting is for the built-in formatter, not prettier. Please see: https://github.com/prettier/prettier-vscode#configuration

[JVimes]

@ntotten, I think maybe you misunderstood. Formatters should all use the IDE's indentation setting, whether they ship with the product or are installed with an extension. This ticket is asking prettier-vscode to behave like users expect. Is there a reason not to?

[ntotten]

After looking into this, it's not possible to handle this case. What we would do is fallback to use the VS Code options if the prettier config options are not set. However, due to the VS Code config API we can't actually tell if the use has set prettier.useTabs or not. The only way to implement this would be to remove our custom config options prettier.tabWidth and prettier.useTabs and only use the built-in options. However, as this would be a breaking change it's not something I think is worth it. Plus there also could be cases where users actually want them separate. For example, if they have one set of options when using the prettier formatter and another set of options when using the built-in formatters.

[JVimes]

Thanks for looking into it, @ntotten. I tend to think that "extension-specific indentation" is a false use case, and is harmful to the experience of practically every user. Was it actually a design decision, or did it just happen incidentally as the extension was written? Please reconsider, especially if anyone else expresses or has expressed trouble getting indentation working. Hopefully there will someday be the API to support fallback. Thanks again for investigating.

[ntotten]

Let me leave this open to gather comments. I'm open to consider it, but it will take some time as we'll have to introduce a breaking change.

[kyro-dev]

I have also noticed this with other languages. No matter how many times I change it in VSCode settings, it never makes a difference.

[yellowjacketcoder]

I think an alternate solution would be to integrate Prettier's prettier.useTabs and prettier.tabWidth into VS Code's status bar using a custom StatusBarItem of VS Code Extension API with the ability to change it just like VS Code's own setting.

[JVimes]

Why have two indentation settings, one unused, even in the status bar? I think extension-specific indentation is not a real use case, even in the status bar.

[JVimes]

I'm not sure this ticket exactly qualifies as a breaking change, since it fixes the expected UX at the expense if a non-feature, I would argue. I think most users will just notice that "indentation starts working".

[thorn0]

Prettier's settings should have priority to make sure that formatting results are consistent across different ways to run Prettier (CLI, extensions for different editors). This is to guarantee that everybody in the team gets the same formatting results.

[JVimes]

I don't agree. In an editor, I expect the indentation setting to work. I don't expect CLI behavior.

[JVimes]

To clarify, it should be the same on CLI, but by using something non-extension-specific, like editorconfig files. Not by implementing a redundant setting.

[thorn0]

@JVimes Prettier's priority is to make sure that

everybody in the team gets the same formatting results

What you want directly contradicts this goal. Maybe Prettier just isn't the right tool for you.

[JVimes]

@thorn0 No, .editorconfig ensures team-wide formatting and is supported by a plethora of editors and tools, so it supports your goal better than Prettier's setting does.

[JVimes]

@thorn0 Let me put it a different way: Prettier's job is to format code, not to enforce that across the team. .editorconfig's job is to enforce that formatting across the team. And it's not okay to break part of VSCode's main UI in order for Prettier Extension to overreach its purpose.

[thorn0]

editorconfig ensures team-wide formatting and is supported by a plethora of editors and tools, so it supports your goal better than Prettier's setting does.

In a way, they're the same as Prettier reads settings from .editorconfig.

Prettier's job is to format code, not to enforce that across the team.

As one of the maintainers, I guess I'm more familiar with the project's goals than you.

[thorn0]

@ntotten

After looking into this, it's not possible to handle this case. What we would do is fallback to use the VS Code options if the prettier config options are not set.

Prettier options are always set. When they're not set explicitly, it's important that their default values are used. So such a fallback is indeed impossible.

[JVimes]

[@thorn0]: As one of the maintainers, I guess I'm more familiar with the project's goals than you.

Maintainer's don't decide user goals. The community does not accept breaking VSCode's main UI as a "goal".

Prettier should read VSCode's setting and VSCode should handle .editorconfig.

[thorn0]

It should be handled the same way it's handled in the EditorConfig extension.

[DanAlexson90]

@thorn0 No, .editorconfig ensures team-wide formatting and is supported by a plethora of editors and tools, so it supports your goal better than Prettier's setting does.

Prettier extension shouldn't rely on the presence of the EditorConfig extension.

[DanAlexson90]

Prettier should read VSCode's setting and VSCode should handle .editorconfig.

VS Code doesn't handle the .editorconfig file, it is the EditorConfig extension that does.