prettier-vscode "Format Selection" works differently on some blocks of code

[nottoseethesun]

./node_modules/.bin/prettier --config ./.prettierrc --write "src/**/*.{ts,tsx}" formats the code as expected, as does vs-code under prettier-vscode "Format Document".

I have no other lint or prettier vs-code extension running other than this one, prettier-vscode. I've reloaded vscode and restarted vscode to be sure.

Yet when I do 'Format Selection' (this is all withprettier-vscode turned on) on some blocks such as this:

  const foo = bar<Bat>(
    baz({
      fooz: bats,
      bazz,
      barz
    } as batz),
    foo1(foo2, foo3(...foo4)) as foo5
  );

get formatted to be all on one line, totally ignoring the 140 line limit set in .prettierrc at the root of my project (alongside package.json).

import statements however are formatted as expected by "Format Selection".

[azz]

Prettier will never collapse that object into one line, so it seems you're invoking some other formatter unintentionally, perhaps the built in one? @CiGit is there a way to find out for sure?

[CiGit]

I've never seen the built in formatter collapse anything. It's mostly only indentation/white-space.

I've tried with your piece of code to format selection by selecting multiple part of this code, it never collapsed. I've found out some other bugs tho :cry:.
Could you give us your config ?
And a reproduction step ?

[nottoseethesun]

.prettierrc :

{
  "parser": "typescript",
  "singleQuote": true,
  "printWidth": 140,
  "jsxBracketSameLine": true
}

To reproduce, I just select the block and do the format-selection command in vscode.

[CiGit]

I come back here after some time (sorry).
do you have eslintIntegration true ?

[FizzBuzz791]

I get this issue too.

Compared to the above, I have the following;

{
    "parser": "babylon",
    "singleQuote": false,
    "printWidth": 80,
    "jsxBracketSameLine": false,
    "eslineIntegration": false
}

Pretty much all the default settings.

I can't seem to set the parser to typescript, it tells me the only valid options are babylon and flow. Both parsers have this issue.

[ronkot]

I think I'm also having this issue (vscode plugin version 1.7.2, prettier version 1.14.3)

I've defined some custom rules in package.json:

 "prettier": {
    "bracketSpacing": false,
    "semi": false,
    "trailingComma": "es5",
    "singleQuote": true,
    "arrowParens": "always"
  }

When running Format document, these configs are respected. When running Format selection, the bracketSpacing behaves like it was true. When re-running Format selection, it behaves again like defined in package.json.

So, it seems that every second run of Format selection behaves like configured.

[varoot]

I can confirm this issue. It seems if you keep rerunning "Format Selection", you'll eventually get the correct result.

So far it seems to me that the number of times you need to run depends on how many things there are to fix. For example, if only trailing comma is missing, I only need to run once. If there is extra space AND missing trailing comma, then the first run only format the space, then the second run will add the comma.

Also, it seems the first run seems to pick up current tab size from VSCode rather than the value in .prettierrc

[BenJenkinson]

I am also experiencing this issue. It seems that the first "Format Selection" does not run prettier or only makes a first pass of edits, since options like singleQuote are ignored. The _second_ time I run "Format Selection", the format looks as I would expect, and as "Format Document" does.

[mathieulj]

I'm also experiencing this issue, although as far as I can tell, I always get different formatting no matter how many times I run Format selection.

With .prettierrc.json

{
    "arrowParens": "always",
    "endOfLine": "lf",
    "overrides": [
        {
            "files": "*.json",
            "options": {
                "tabWidth": 2
            }
        }
    ],
    "singleQuote": true,
    "tabWidth": 4,
    "trailingComma": "es5"
}

Format on save gives me (base indent removed for clarity):

template = Graph.TooltipTemplate({
    formattedTime,
    formattedYPoint: Formatter.numericRaw(value),
});

Whereas Format selection gives me (base indent removed for clarity):

template = Graph.TooltipTemplate(
    {
        formattedTime,
        formattedYPoint: Formatter.numericRaw(
            value
        ),
    }
);

Edit:

Toying around with this specific case; if I add four indent levels to my code, the Format on save matches the Format selection example above (same formatting). On the other hand, if I set printWidth to 120 in my prettierrc, both Format selection and format on save match the Format on save above (expected beheviour). It thus seems as though (at least in my case), the issue stems from an incorrect indent starting point for the format selection as if the context/base shift in indent sent to prettier during the format selection (I'm not sure how this is implemented under the hood) is incorrect.

[mathieulj]

It seems, at least in my case, this may be an upstream issue.

I tried debugging the extension and noticed that the options sent down to prettier corresponded to :

yarn prettier --arrow-parens always --end-of-line lf --parser babel --printWidth 80 --range-end 10523 --range-start 10335 --single-quote true --tab-width 4 --trailing-comma es5 <the file>

Running that gives the same result as the Format selection. Simply removing the range:

yarn prettier --arrow-parens always --end-of-line lf --parser babel --printWidth 80  --single-quote true --tab-width 4 --trailing-comma es5 <the file>

Gives the expected result.

Edit: upstream issue https://github.com/prettier/prettier/issues/6046

[CiGit]

As pointed by @mathieulj, An issue with prettier.
Thanks for fixing it @mathieulj ;-)

[mathieulj]

Your very welcome.

Although I must add the note/caveat that the bug I fixed explains the behaviour I was seeing but doesn't explain some of the other behaviours highlighted in this issue. My fix only resolves the print width inconsistencies between ranged and whole file formatting (resulting in formatting difference).

[ntotten]

Looks like this was a prettier issue and is now fixed.

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.