Prettier-vscode: FormatOnSave takes a long time

Created on 16 Apr 2020  路  23Comments  路  Source: prettier/prettier-vscode

Summary

Frequently, when I save a file with FormatOnSave option on, it takes forever to finish saving. I have to quit VS Code and restart. Then, save happens instantaneously again. After a while, the issue re-appears. The identical issue to this one: https://github.com/prettier/prettier-vscode/issues/1253. Not at all clear why that issue is closed -- clearly people are having this problem.

Github Repository to Reproduce Issue

https://github.com/prettier/prettier-vscode/issues/1253

Steps To Reproduce:

https://github.com/prettier/prettier-vscode/issues/1253

Expected result

Doesn't take a long time to save.

Actual result

Took forever to save.

Additional information

Obviously, many people are having this same problem. This issue (https://github.com/prettier/prettier-vscode/issues/1253) should not be closed.

VS Code Version:

Prettier Extension Version:

OS and version:

Prettier Log Output


LOG GOES HERE. DO NOT USE A SCREESHOT, COPY AND PASTE THE TEXT
investigation

Most helpful comment

@ntotten I'm able to mostly consistently repro this,

  1. git clone https://github.com/Automattic/wp-calypso.git
  2. Open the repo with vscode and prettier (or eslint plugin as we use the prettier eslint plugin).
  3. Open this file
  4. Add a couple of newlines and save to confirm format on save is working as expected
  5. Delete this fragment close line, you may need to add some tabs/line blanks to trigger it.
  6. Saving, you should see eslint give you 70 odd errors
  7. Add the fragment close back
  8. Save again, you should find that the preceding errors were not cleared and the format will no longer run, instead it "hangs" and uses 100% cpu (well on one thread anyway)

I'm not sure where the failure is really happening, probably on the first save after line delete and then isn't recovering on the second.

This problem happens both with the prettier plugin or the eslint vscode plugin (because we use the prettier plugin for eslint.)

The only way I've found to recover from this state is to sigterm the electron thread at 100% load or to restart vscode (at which point, with the replaced fragment close, will continue to format correctly)

I suspect this is hard to repro because it probably has more to do with the large number of cascading errors that stems from removing one fragment closure line than removal of the line itself. You probably also need a significantly complicated enough file to trigger the failure mode.

All 23 comments

Same there. Not sure what exactly causes that... but in my case it happens when i:
1) First modify an SVG XML inside of tagged template literals like:

export const ChevronRight = (): SVGTemplateResult => svg'
    <svg id="i-chevron-right" viewBox="0 0 32 32">
        <path d="M12 30 L24 16 12 2" />
    </svg>
'

2) And then trying to save some other file.ts typescript file which imports that SVG object.

Prettier hangs up exactly when saving file.ts.
image
If i press Cancel then i get this on next save:
image

Only Reload Window helps, but it's annoying as hell as i should start dev server all the time.
I tried to use (enable/disable/uninstall) several tagged template literal plugins - the result is same. Prettier always gets on my way.

More over - i have no any hints (which plugin or other info) from Prettier itself, how could i debug that.

The issue you referenced was closed because I can鈥檛 reproduce the bug. If someone can provide a valid repro I鈥檓 happy to try to fix it, but that bug nor this one has enough info. This extension has millions of monthly users. Clearly not everyone is having this issue. Please provide repro step and I鈥檒l investigate.

This same issue happens when I try to save .md files on VSCode sometimes. But when I cancel and resave the file, it works.

I'm having the same issue as well and have been for a while now. It's a private repo with an NDA type of situation so I can't really share that. I don't know what this could be.

prettier

Same Issue here
image

I was never able to solve this issue and I spent countless hours debugging it over the course of two very frustrating months that it was happening. I eventually realized that I was wasting an absurd amount of time on this one problem and I uninstalled every version of VS Code that I had on my computer. I deleted all the temporary files, cleared the caches, started with a fresh install and reinstalled all of my extensions once again.

When I tried to back everything up before taking the nuclear option, the problem just persisted so I realize I had to wipe everything out if I was going to truly fix this.

Once I started reinstalling extensions, it became apparent that I have really customized my editor to my liking over the past several months and I thought that I would be able to remember all of the settings that I was using but I couldn't even come close. I ended up having to play with a lot of settings and extensions to get everything to feel normal for me again since I work largely with VueJS.

Now I don't have the issue anymore but I was never able to get to the bottom of it and I tried hard.

It's the worst kind of bug because you don't get any logs to reference regarding what's happening behind the scenes, other people can't reproduce it because I think it has something to do with your settings (ESLint, Prettier, Vetur, etc...)

Save yourself the headache and just make note of the important settings. Go for a fresh install and try to make sure that you don't have too many things which could effect formatting.

That's the best solution I could find even after consulting associates and friends for help. Everyone was stumped.

I agree with @716green , but the truth is that I have done a clean installation and it continues to happen, with only the Prettier extension.

@ntotten I'm able to mostly consistently repro this,

  1. git clone https://github.com/Automattic/wp-calypso.git
  2. Open the repo with vscode and prettier (or eslint plugin as we use the prettier eslint plugin).
  3. Open this file
  4. Add a couple of newlines and save to confirm format on save is working as expected
  5. Delete this fragment close line, you may need to add some tabs/line blanks to trigger it.
  6. Saving, you should see eslint give you 70 odd errors
  7. Add the fragment close back
  8. Save again, you should find that the preceding errors were not cleared and the format will no longer run, instead it "hangs" and uses 100% cpu (well on one thread anyway)

I'm not sure where the failure is really happening, probably on the first save after line delete and then isn't recovering on the second.

This problem happens both with the prettier plugin or the eslint vscode plugin (because we use the prettier plugin for eslint.)

The only way I've found to recover from this state is to sigterm the electron thread at 100% load or to restart vscode (at which point, with the replaced fragment close, will continue to format correctly)

I suspect this is hard to repro because it probably has more to do with the large number of cascading errors that stems from removing one fragment closure line than removal of the line itself. You probably also need a significantly complicated enough file to trigger the failure mode.

I have been seeing this over the past couple of days. It has been very frequent and happens even for files that have had a 1 line change.

seeing it as well. for filesizes as small as 66 lines, probably less too.

@lsl Thanks for the repo, i will investigate when time allows.

Seeing this issue also.

I observe a few minutes of waiting...

Same issue here.

Same issue here

鈽濓笍

Had the same problem and solved it by cleaning up my settings.json

Same issue here

same issue

same here

I experienced this last week on a Typescript React project, however, I also got this problem while working on a Go project just now. Code action on Save took a while and failed to auto format and auto import packages. This is probably an issue with VS Code itself and not the VS Code prettier plugin.

I was working in a Workspace with multiple folder paths (3). 2 of which were Go projects and the third being a general data folder which has one html file in it. My workspaces are pretty much Go files though.

Same.

same

same

Was this page helpful?
0 / 5 - 0 ratings

Related issues

finalclass picture finalclass  路  4Comments

ZiiMakc picture ZiiMakc  路  4Comments

peralmq picture peralmq  路  3Comments

Connorelsea picture Connorelsea  路  4Comments

FlorianWendelborn picture FlorianWendelborn  路  3Comments