vscode format on save on big file cursor alway jump to the end of the file

[Kyrosee]

Format on save on big js file(3700lines), cursor alway jump to the end of the file
prettier version 9.10.4
vscode 1.76.2

[madc0w]

I can confirm that this is a real issue, and it's driving me nuts.
Same prettier & vscode versions as the OP.

The precise file size at which this behavior begins occurring is 100002 bytes. That is, formatting a file with 100001 bytes is fine, but adding one more byte breaks prettier. At least, this is true for a Javascript file. I've not tested other types.

Here is my test. (I had to put it in a zip file, since the .js extension is not an allowed type for attaching.)
test.zip

[foaudkajj]

+1 having the same problem.

[marekcambal]

yes, I can confirm the same issue
file being edited has ~3600 lines

vscode 1.76.2
prettier version 9.10.4

setting source.organizeImports to false prevents cursor jumping to EOF

"editor.codeActionsOnSave": {
    "source.organizeImports": false,
  },

[foaudkajj]

@marekcambal, please be aware that changing the setting only fixes the problem that happens while saving the file (with save on format flag is true).
When the file is formatted with alt+shift+f combination, the cursor is jumping to the EOF.

[VanguardaSistemas]

Same issue here

[ValentinLeTallec]

Same here, except that with

• a ~5000 lines file
• vscode 1.77.3
• prettier 9.10.4

marekcambal's workaround did not work for me

[dnjat]

+1 crazy

[hdrodel]

Having the same issue. Is there a workaround for this ?

[dnjat]

bug +1. this is bug,no enhancement

[liboz]

I was able to determine that the bug was introduced in 9.5. Reverting to version 9.4 fixes the issue. Looking at the commit log, be790ca seems very suspect.

I changed the mode locally to just modifications but then prettier doesn't run at all. I'm guessing that the algorithm to get only the modified part is too costly to run for very large files. Though that doesn't quite make sense either as manually using the format is still fast (~180ms). VS code might just be having issues for whatever reason for very large files on modification only changes.

The solution is probably to only use the "new" algorithm when the setting is enabled.

But for now reverting to 9.4 will work and that's what I've done.

@ntotten @rotu

[rotu]

I was able to determine that the bug was introduced in 9.5. Reverting to version 9.4 fixes the issue. Looking at the commit log, be790ca seems very suspect.

I don't remember exactly why my change allows range formatting to work. I think it was because prettier always reports that it changed the entire file and this would overlap with some other edit ranges from somewhere else. VSCode would see the conflicting edits and bail.

Because of @madc0w's analysis, I searched for "100000", in VSCode, and this looks like a contributing factor: https://github.com/microsoft/vscode/blob/f125afbc800ec611f5a9ab1333c769832ce424b3/src/vs/editor/common/services/editorSimpleWorker.ts#L492

Looking at the blame, that line was last changed to fix vscode#72321 and the discussion there seems very relevant.

[38b3eff8]

+1

[TheSecurityDev]

Just came across this issue after the file got larger. Previously it was working fine but now this particular file always jumps to the bottom. I have prettier configured to format on save, so saving causes this issue, which is extremely annoying since I save often.