microsoft / vscode-eslint

VSCode extension to integrate eslint into VSCode
MIT License
1.7k stars 330 forks source link

vscode-eslint extension not working on latest version of VSCode, v1.90.0 #1856

Open D-Maher opened 3 weeks ago

D-Maher commented 3 weeks ago

Environment

Operating System: macOS VSCode Version: 1.90.0 vscode-eslint Version: 2.4.4 ESLint Version: 8.45.0 eslint-plugin-prettier Version: 5.0.0

Description

This extension does not appear to be formatting code when setting "source.fixAll.eslint" in VSCode's editor.codeActionsOnSave settings. When saving a file, the extension hangs indefinitely without much indication in the ESLint Output of what could be going on.

This is an issue I've noticed happening in the last two days or so, and it seems to coincide with updating to the May 2024 release of VSCode, v1.90.0. When downgrading to VSCode v1.89.1, the issue disappears entirely.

I'm not sure if this is an issue with compatibility between the extension and the latest version of VSCode or if this is a bug in VSCode itself, but I'm inclined to think it's the former since other code actions I have configured to run on save (e.g. "source.organizeImports") run just fine on VSCode v1.90.0.

Additional Information

The extension appears to start up just fine based on what I'm seeing in the ESLint Output:

[Info  - 11:18:37 AM] ESLint server is starting.
[Info  - 11:18:38 AM] ESLint server running in node v20.9.0
[Info  - 11:18:38 AM] ESLint server is running.
[Info  - 11:18:39 AM] ESLint library loaded from: /my/obfuscated/path/to/.yarn/sdks/eslint/lib/api.js

[!NOTE]
This particular project is on Yarn v4.0.2 so there is an ESLint SDK installed, hence the path in the logs above.

But when saving a file, I see this pop-up at the bottom right of VSCode that seems to hang there indefinitely:

code_actions_hanging

I've tried hitting 'Cancel' and then running the ESLint: Restart ESLint Server command, but then I get the following pop-up:

restart_failed

And the ESLint output displays the following:

[Error - 11:22:35 AM] Restarting client failed
Error: Stopping the server timed out
    at /my/obfuscated/path/to/.vscode/extensions/dbaeumer.vscode-eslint-2.4.4/client/out/extension.js:1:105150
    at b.restart (/my/obfuscated/path/to/.vscode/extensions/dbaeumer.vscode-eslint-2.4.4/client/out/extension.js:1:270303)

I've also run an extension bisect in VSCode and that did not identify any other extensions as the potential culprit here.

I'm happy to provide additional information if helpful.

cwsault commented 3 weeks ago

Seeing this as well since the VSCode update; seems to be related to using eslint-plugin-prettier & yarn's PNP loading.

I can reproduce it on a fresh project with the following steps, on multiple systems --

  1. yarn create vite some-project-name
  2. choose react & TS; cd into project
  3. add "packageManager": "yarn@4.2.2", to package.json
  4. yarn or yarn install
  5. yarn add --dev eslint-plugin-prettier eslint-config-prettier prettier
  6. add 'plugin:prettier/recommended' to extends block of .eslintrc.cjs
  7. yarn dlx @yarnpkg/sdks vscode
  8. open project in VSCode; edit & attempt to save a .ts or .tsx file

You'll also notice if you go to VSCode's Help -> Process Explorer that upon open a TS file, the ESLint server will die immediately upon starting (listed as 'defunct') -- probably related to https://github.com/microsoft/vscode-eslint/issues/1855 as well (in fact, the server dying is the real issue; it occurs even if you don't have fix-on-save enabled. based on logs it seems to happen while still loading)

If plugin:prettier/recommended is not included in the eslintrc then the problem does not occur. If yarn is configured to use node_modules installation ( echo nodeLinker: node-modules >> .yarnrc.yml ) then the problem also does not occur. Also no issue when using npm instead of yarn.

D-Maher commented 3 weeks ago

@cwsault, good info! I've got eslint-plugin-prettier configured too.

jrmymbtlr commented 3 weeks ago

Interesting. I didn't have prettier or prettier extensions installed, but I removed an older .prettierrc and restarted ESLint, and it started working.

I'm almost sure it's just a coincidence.

ottobonn commented 3 weeks ago

We are seeing the same issue after updating to VSCode 1.90, running on Mac OS, using yarn PNP with eslint and prettier and "editor.codeActionsOnSave": { "source.fixAll": "explicit" } in our project settings. When saving TypeScript files, the editor waits indefinitely at "Getting Code Actions."

I can also confirm that when restarting the ESLint server, it fails with "stopping the server timed out," but before explicitly trying to restart it, I don't see errors in its output.

dbaeumer commented 3 weeks ago

This is very likely related to https://github.com/yarnpkg/berry/issues/6219.

Can you see if upgrading to yarn 4.3 changes anything.

dbaeumer commented 3 weeks ago

I tired it wit yarn 4.3.0 and I couldn't make the server crash.

joonaathaan commented 2 weeks ago

I've had the same issue since VSCode May release last Thursday. I've tested in both cjs and mjs, I'm using flat config with yarn pnp.

Apple Silicon, VSCode 1.90, Yarn Berry v4.3.0 "eslint": "^9.4.0", "eslint-config-prettier": "^9.1.0", "eslint-plugin-prettier": "5.1.2", (tested 5.1.3) "prettier": "3.1.1", (tested 3.3.1 and 3.3.2) "typescript": "5.4.3"

// eslint.config.mjs
import eslintPluginPrettier from 'eslint-plugin-prettier/recommended';
export default [eslintPluginPrettier];

After 2-3 days of research i decided to follow the debugging technique since it was my last option (here) It seems that whenever 'prettier/prettier' rule is present, the prettier plugin crashes and causes the infinite hang on "Getting code actions from...". I've reached this conclusion after copying the recommended flat config from the prettier-plugin package and removing this rule stopped the crash.

// debugger logs
[Info  - 4:07:21 PM] ESLint library loaded from: /Users/xxxxxx/Work/xxxxxx/.yarn/sdks/eslint/lib/api.js
[Error - 4:07:22 PM] An unexpected error occurred:
[Error - 4:07:22 PM] Error: synckit tried to access ", but it isn't declared in its dependencies; this makes the require call ambiguous and unsound.

Required package: " (via ""/Applications/Visual")
Required by: synckit@npm:0.8.8 (via /Users/xxxxxx/.yarn/berry/cache/synckit-npm-0.8.8-f5ee4a6dac-10c0.zip/node_modules/synckit/lib/)

Require stack:
- /Users/xxxxxx/.yarn/berry/cache/synckit-npm-0.8.8-f5ee4a6dac-10c0.zip/node_modules/synckit/lib/index.cjs
- /Users/xxxxxx/Work/xxxxxx/.yarn/__virtual__/eslint-plugin-prettier-virtual-288b79f086/3/.yarn/berry/cache/eslint-plugin-prettier-npm-5.1.2-d18bb6313f-10c0.zip/node_modules/eslint-plugin-prettier/eslint-plugin-prettier.js
- /Users/xxxxxx/Work/xxxxxx/eslint.config.cjs
Occurred while linting /Users/xxxxxx/Work/xxxxxx/eslint.config.cjs:1
Rule: "prettier/prettier"
    at Function._resolveFilename (/Users/xxxxxx/Work/xxxxxx/.pnp.cjs:8329:13)
    at Function.resolve (node:internal/modules/helpers:136:19)
    at /Users/xxxxxx/.yarn/berry/cache/synckit-npm-0.8.8-f5ee4a6dac-10c0.zip/node_modules/synckit/lib/index.cjs:205:92
    at Array.some (<anonymous>)
    at setupTsRunner (/Users/xxxxxx/.yarn/berry/cache/synckit-npm-0.8.8-f5ee4a6dac-10c0.zip/node_modules/synckit/lib/index.cjs:204:68)
    at startWorkerThread (/Users/xxxxxx/.yarn/berry/cache/synckit-npm-0.8.8-f5ee4a6dac-10c0.zip/node_modules/synckit/lib/index.cjs:285:7)
    at Object.createSyncFn (/Users/xxxxxx/.yarn/berry/cache/synckit-npm-0.8.8-f5ee4a6dac-10c0.zip/node_modules/synckit/lib/index.cjs:90:18)
    at Program (/Users/xxxxxx/Work/xxxxxx/.yarn/__virtual__/eslint-plugin-prettier-virtual-288b79f086/3/.yarn/berry/cache/eslint-plugin-prettier-npm-5.1.2-d18bb6313f-10c0.zip/node_modules/eslint-plugin-prettier/eslint-plugin-prettier.js:165:51)
    at ruleErrorHandler (/Users/xxxxxx/.yarn/berry/cache/eslint-npm-9.4.0-fe5b02f3aa-10c0.zip/node_modules/eslint/lib/linter/linter.js:1115:48)
    at /Users/xxxxxx/.yarn/berry/cache/eslint-npm-9.4.0-fe5b02f3aa-10c0.zip/node_modules/eslint/lib/linter/safe-emitter.js:45:58

Steps to reproduce

cwsault commented 2 weeks ago

Still occurs for me using "packageManager": "yarn@4.3.0", instead of 4.2.2

shermify commented 2 weeks ago

I tried a bunch of yarn versions including latest build and it doesn't work for me. I'm thinking it might have something to do with the jump to node 20 and changes to the way commonjs/ES modules are resolved.

shermify commented 2 weeks ago

Here is a simple reproduction with 1 file. Just need to run yarn install. When you open index.js, you don't get any formatting highlights for prettier and when you try to save, it freezes up. This is on VSCode 1.90

https://github.com/shermify/eslint-plugin-repro

dbaeumer commented 2 weeks ago

I was able to reproduce this and I am pretty confident that this has nothing to do with the ESLint extension itself. The underlying problem is that prettier is using the syncKit to call sync into a worker which blocks the eslint server. For some reason the worker newer return and therefore the server is hanging here:

Image

dbaeumer commented 2 weeks ago

Prettier creates the sync function with:

              prettierFormat = require('synckit').createSyncFn(
                require.resolve('./worker'),
              );

where require.resolve('./worker') resolve to

'/workspaces/eslint-plugin-repro/.yarn/__virtual__/eslint-plugin-prettier-virtual-bc1e252fbd/0/cache/eslint-plugin-prettier-npm-5.1.3-496c3b84df-f45d5fc1fc.zip/node_modules/eslint-plugin-prettier/worker.js'

It looks like that this makes the worker fail which makes the Atomics.wait never return.

dbaeumer commented 2 weeks ago

This is nothing I can fix in the ESLint extension itself. I opened https://github.com/yarnpkg/berry/issues/6335

Since things seemed to work with Node 18.18.2 you could install that version and use the eslint.runtime setting to point to that version.

shermify commented 2 weeks ago

If anyone needs to fix this immediately, you can use this yarn patch on eslint-plugin-prettier. Basically just change the dynamic import in worker.js to a require and point it to prettier/index.cjs

diff --git a/eslint-plugin-prettier.js b/eslint-plugin-prettier.js
index 74cd8c0497dadb3a79226bd059845a0fb662a697..cc7b6f7bcb2587d541e042c9e25fd76cf43936f8 100644
--- a/eslint-plugin-prettier.js
+++ b/eslint-plugin-prettier.js
@@ -164,7 +164,7 @@ const eslintPluginPrettier = {
             if (!prettierFormat) {
               // Prettier is expensive to load, so only load it if needed.
               prettierFormat = require('synckit').createSyncFn(
-                require.resolve('./worker'),
+                require.resolve('./worker.js'),
               );
             }

diff --git a/worker.js b/worker.js
index 8a8a802ca719a55f4d2ae526eb54e712edfd7455..06269d1c27ca49fd9c7da320318872aa7f40f4f5 100644
--- a/worker.js
+++ b/worker.js
@@ -7,11 +7,10 @@
  */

 const { runAsWorker } = require('synckit');
-
+const prettier = require('prettier/index.cjs')
 /**
  * @type {typeof import('prettier')}
  */
-let prettier;

 runAsWorker(
   /**
@@ -32,9 +31,6 @@ runAsWorker(
     },
     eslintFileInfoOptions,
   ) => {
-    if (!prettier) {
-      prettier = await import('prettier');
-    }

     const prettierRcOptions = usePrettierrc
       ? await prettier.resolveConfig(onDiskFilepath, {
joonaathaan commented 2 weeks ago

I've tried the patch, it didn't seem to work sadly. In the meantime downgrading vsc to april's release seems to be the best option, everything is working properly since it's on node 18.18.2

shermify commented 2 weeks ago

You also need to run yarn unplug eslint-plugin-prettier. I'm not sure why it also needs to be unplugged, but it should work unless this is an issue across more plugins, which is possible

PavelOparin commented 2 weeks ago

Hello everyone. For me setting up "eslint.runtime": "node" helped to fix this problem without removing or fixing prettier plugin. Without this settings eslint used node 20.* when I actually have 18.14 and this settings force him to use my version and looks like this solves problem.

hanyufoodles commented 1 week ago

By unplugging with yarn unplug eslint-plugin-prettier and applying the patch from @shermify, the extension v3.0.10 works again under node v20 and yarn pnp.