You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
Jeytastic, hdrodel, batflarrow, rotu and Bahman-Lugano
@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.
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.
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.
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.
justin-haworth, Bahman-Lugano, blidblid and zhangzhen24
Any resolution on this issue? It's very annoying and counterproductive. Please fix this as it seems to be a straight forward and easy fix especially since the older versions of prettier don't seem to have the same issue.
tl;dr: Its a problem with inconsistent line endings between the editor and prettier defaults. Ensure consistent line endings in prettier and VSCode.
Would be great if affected people here can confirm my assumptions for their environment.
deeper insights
My setup:
.prettierrc - No setting (defaults to LF)
I am on Windows with auto crlf on git level
I have a editorconfig which would force LF
I have no gitattributes which would force LF, hence git applies auto CRLF and my files are with CRLF
vscode auto-detects the line endings from the content and sets the editor to CRLF
When formatting I see in the output window: "endOfLine": "lf"
As soon I change the settings to be consistent (in VSCode or in prettier) the jumping disappears. I guess one leads to another and messes up the offsets:
Prettier delivers \n lines for the partial edit
Prettier vscode tries to calculate the correct text range for the optimized edit but its not very optimized anymore:
only the first line of the file until the line ending matches leading almost to a full file replace.
The file is replaced almost fully with the \n string.
From what I see VSCode replaces again the line endings with CRLF.
Somewhere in VSCode the cursor gets messed up.
Unless I find another spot where prettier-vscode is to blame, we need to carry this to microsoft/vscode.
Prettier and prettier-vscode are doing things correctly. As per expectation they replace the content to be with LF instead of CRLF.
prettier-vscode could try to change the editor mode to match the configured setting. This should eliminate the problem on subsequent formats. (
A new prettier-vscode option could help for project where changing stuff is hard (project not owned, big impact of the change): The new option would force prettier-vscode to use the editor line ending instead of the one from the config.
For (2) I gave it locally a quick shot to implement it. As you can see it jumps on the first formatting and it updates the editor to to LF. After that the formatting seem to act normally.
Activity
madc0w commentedon Mar 23, 2023
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 commentedon Mar 24, 2023
+1 having the same problem.
marekcambal commentedon Mar 24, 2023
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 EOFfoaudkajj commentedon Mar 24, 2023
@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 commentedon Mar 28, 2023
Same issue here
ValentinLeTallec commentedon Apr 13, 2023
Same here, except that with
marekcambal's workaround did not work for me
dnjat commentedon Jul 9, 2023
+1 crazy
hdrodel commentedon Aug 2, 2023
Having the same issue. Is there a workaround for this ?
dnjat commentedon Aug 16, 2023
bug +1. this is bug,no enhancement
liboz commentedon Aug 20, 2023
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 commentedon Aug 20, 2023
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 commentedon Jul 23, 2024
+1
TheSecurityDev commentedon Aug 3, 2024
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.
Bahman-Lugano commentedon Oct 30, 2024
Any resolution on this issue? It's very annoying and counterproductive. Please fix this as it seems to be a straight forward and easy fix especially since the older versions of prettier don't seem to have the same issue.
obinecko commentedon Feb 20, 2025
well looks like still nothing
Danielku15 commentedon Apr 2, 2025
I narrowed down the problem for my project! 🥳
tl;dr: Its a problem with inconsistent line endings between the editor and prettier defaults. Ensure consistent line endings in prettier and VSCode.
Would be great if affected people here can confirm my assumptions for their environment.
deeper insights
My setup:
.prettierrc
- No setting (defaults to LF)"endOfLine": "lf"
As soon I change the settings to be consistent (in VSCode or in prettier) the jumping disappears. I guess one leads to another and messes up the offsets:
\n
lines for the partial edit\n
string.Unless I find another spot where
prettier-vscode
is to blame, we need to carry this to microsoft/vscode.prettier-vscode/src/PrettierEditService.ts
Line 134 in b8d9e42
editBuilder.setEndOfLine
For (2) I gave it locally a quick shot to implement it. As you can see it jumps on the first formatting and it updates the editor to to LF. After that the formatting seem to act normally.
Code_RLbljKe7Wh.mp4
thxSakura commentedon Jun 5, 2025
"prettier.endOfLine": "auto"
fix for me