Skip to content

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

Open
@Kyrosee

Description

@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

Activity

madc0w

madc0w commented on Mar 23, 2023

@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

foaudkajj commented on Mar 24, 2023

@foaudkajj

+1 having the same problem.

marekcambal

marekcambal commented on Mar 24, 2023

@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

foaudkajj commented on Mar 24, 2023

@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

VanguardaSistemas commented on Mar 28, 2023

@VanguardaSistemas

Same issue here

ValentinLeTallec

ValentinLeTallec commented on Apr 13, 2023

@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

added
help-wantedNot something we plan on doing, but we will take a pull request.
on Apr 21, 2023
dnjat

dnjat commented on Jul 9, 2023

@dnjat

+1 crazy

hdrodel

hdrodel commented on Aug 2, 2023

@hdrodel

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

dnjat

dnjat commented on Aug 16, 2023

@dnjat

bug +1. this is bug,no enhancement

liboz

liboz commented on Aug 20, 2023

@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

rotu commented on Aug 20, 2023

@rotu
Contributor

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

38b3eff8 commented on Jul 23, 2024

@38b3eff8

+1

TheSecurityDev

TheSecurityDev commented on Aug 3, 2024

@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.

Bahman-Lugano

Bahman-Lugano commented on Oct 30, 2024

@Bahman-Lugano

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

obinecko commented on Feb 20, 2025

@obinecko

well looks like still nothing

Danielku15

Danielku15 commented on Apr 2, 2025

@Danielku15

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)
  • 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.

  1. Prettier and prettier-vscode are doing things correctly. As per expectation they replace the content to be with LF instead of CRLF.
  2. prettier-vscode could try to change the editor mode to match the configured setting. This should eliminate the problem on subsequent formats. (
    editBuilder.replace(edits[0].range, edits[0].newText);
    -> editBuilder.setEndOfLine
  3. prettier-vscode could warn users about the inconsistency in their project setup. (refer to https://prettier.io/docs/options#end-of-line)
  4. 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.

Code_RLbljKe7Wh.mp4
thxSakura

thxSakura commented on Jun 5, 2025

@thxSakura

"prettier.endOfLine": "auto"
fix for me

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementhelp-wantedNot something we plan on doing, but we will take a pull request.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @rotu@ntotten@madc0w@Danielku15@38b3eff8

        Issue actions

          vscode format on save on big file cursor alway jump to the end of the file · Issue #2920 · prettier/prettier-vscode