vscode-eslint: eslint.autoFixOnSave does not trigger consistently

Hi šŸ‘‹

First of all, thanks a lot for your work, this plugin is amazing and I use it everyday !

Unfortunately, sometimes (as described in eslint.autoFixOnSave doesnā€™t always fire on save #283) eslint shows all file errors correctly but does not trigger the file fixes on save when the setting is correctly set in vscode settings (either in User or Workspace settings).

As asked in #283 I set the setting eslint.server.trace to ā€œmessagesā€ and observed that when the plugin does not work as expected this lines are not shown in the trace logs:

[Trace - 3:46:33 PM] Sending request 'textDocument/willSaveWaitUntil - (2)'.
[Trace - 3:46:33 PM] Received response 'textDocument/willSaveWaitUntil - (2)' in 110ms.

They are outputted just before textDocument/didSave in the normal situation, but not when the plugin does not fixe on save.

Also, Reload Window solves the issue temporarily, until it breaks again.

PS: Iā€™m sorry because I just reload before sending this issue, so I donā€™t have the trace logs when it does not work. Iā€™m add them in a following comment.

Thanks in advance for your time !

About this issue

  • Original URL
  • State: closed
  • Created 5 years ago
  • Reactions: 19
  • Comments: 75 (20 by maintainers)

Most upvoted comments

Happens to me all the time as well. It will work for a short while, then suddenly just stop working. My workaround is to restart vscode.

After removing this editor.defaultFormatter - autofix works like a charm, and willSaveWaitUntil is showing in output.

I discovered it works with editor.defaultFormatter, you just have to add

"eslint.validate": [
  { "language": "typescript", "autoFix": true },
  { "language": "typescriptreact" , "autoFix": true} // If you use React
]

So the combination of autoFixOnSave and autoFix works, donā€™t know why though.

I added "editor.codeActionsOnSaveTimeout": 2000 to my config and it successfuly formated the problematic piece without even reloading the app.

From eslint plugin description: ā€œAlso note that there is a time budget of 750ms to run code actions on save which might not be enough for large JavaScript / TypeScript file. You can increase the time budget using the editor.codeActionsOnSaveTimeout setting.ā€

That would explain why it was so random.

Iā€™m still having this problem. But it happens randomly. Itā€™s hard to reproduce.

Iā€™m having this problemā€¦ I just set up eslint/prettier with my project and it was working beautifully. In the middle of coding, it stopped, and restarting has not helped me šŸ˜¢

@diegohaz thanks for the additional information. It indeed helps. So I think what is happening is the following:

  • there is a time budget in VS Code for the willSaveWaitUntil hook of 1.5 sec
  • if you violate it three times it is not called anymore.
  • there is an entry [Trace - 18:58:01] Received response 'textDocument/willSaveWaitUntil - (480)' in 1994ms. after which the fixing stops working which took 1994 ms.

Fixing this is not easy since the VS Code time budget is fixed and not dependent on file size. The thing I can look into is to turn this into code actions which at least have a setting so users can increase the budget. This is not possible for the will save hook.

Disable to default formatter of vs code and it will work.

Screenshot 2019-10-10 at 12 24 41 PM

@kdegrace Exactly the same problems!!! Frustrating šŸ˜¢

For anyone having troubles with eslint, make sure the folder in your workspace is the root of your project. Adding a folder that is not the root of the project makes eslint server look at that instead of your project and canā€™t load.

Eg. If add a folder that contains many projects you wonā€™t get linting or formatting unless you add an eslintrc file to it. Just add project folders separately so that eslint serve will run for each projetc. I hope this explains the solution well.

Disable to default formatter of vs code and it will work.

Screenshot 2019-10-10 at 12 24 41 PM

nopeā€¦

Can someone that sees this enable server tracing to find out if the corresponding messages are still sent to ESLint. To do so add the following setting:

"eslint.trace.server": "messages"

and provide the Output from the ESLint channel here. Thanks!

Confirming that this issue persists. If you restart VScode it will work for a bit of time!

Iā€™m having the same problem. Interesting fact is that it NEVER autofixes .ts files after save (and yes, I enabled it in settings, calling autofix manually works), but it always works for .js files. Similar symptoms as above, for .ts files I only see this in output:

[Trace - 6:39:42 PM] Sending notification 'textDocument/didSave'.

For regular .js files:

[Trace - 6:40:33 PM] Sending request 'textDocument/willSaveWaitUntil - (4)'.
[Trace - 6:40:33 PM] Received response 'textDocument/willSaveWaitUntil - (4)' in 1ms.
[Trace - 6:40:33 PM] Sending notification 'textDocument/didChange'.
[Trace - 6:40:33 PM] Sending notification 'textDocument/didSave'.
[Trace - 6:40:33 PM] Received notification 'textDocument/publishDiagnostics'.
[Trace - 6:40:33 PM] Received notification 'eslint/status'.

Edit: Looks like Iā€™ve found the problem, it was this setting in settings.json:

"[typescript]": {
    "editor.defaultFormatter": "vscode.typescript-language-features"
  }

After removing this editor.defaultFormatter - autofix works like a charm, and willSaveWaitUntil is showing in output.

Yup, itā€™s configured properly. Still having problems though:

  "files.autoSave": "off",
  "eslint.trace.server": "messages",
  "eslint.autoFixOnSave": true,

It really seems to depend on the project. Some projects, it works OK, but others it just wonā€™t work at all, unless I try reloading a bunch of times.

I met same problem, it solved by @verbumfeit 's solution. Thanks a lot verbumfeit !

@dbaeumer I think I have a start of an answer! After a search and replace a string in multiple files, the autoFixOnSave is not working anymore!

Having the same problem here. autoFixOnSave just stops working altogether. Very sporadic it seems. Iā€™m not seeing any output in the log either (although maybe Iā€™m looking in the wrong placeā€¦?)