keep getting "LSP :: ESLint is not configured correctly"

[aspiers]

I keep seeing this error when opening new TypeScript files:

LSP :: ESLint is not configured correctly. Please ensure your eslintrc is set up for the languages you are using 

and even though the eslint server still seems to be working, it seems quite slow, and I'm wondering if the slowness is related to this error.

However I cannot reproduce via emacs -q -l lsp-start-plain.el, so I'm not filing as a bug but instead pleading for help here.

I see that the error comes from lsp-eslint--probe-failed:

lsp-mode/clients/lsp-eslint.el

Lines 344 to 346 in 8f9259a

	(defun lsp-eslint--probe-failed (_workspace _message)
	"Called when the server detects a misconfiguration in ESLint."
	(lsp--error "ESLint is not configured correctly. Please ensure your eslintrc is set up for the languages you are using."))

and is triggered via:

lsp-mode/clients/lsp-eslint.el

Lines 365 to 367 in 8f9259a

	:request-handlers (ht ("workspace/configuration" #'lsp-eslint--configuration)
	("eslint/openDoc" #'lsp-eslint--open-doc)
	("eslint/probeFailed" #'lsp-eslint--probe-failed))

which seems to possibly come from this logic in the eslint server:

https://github.com/microsoft/vscode-eslint/blob/034172f464917127fa6b6625800b83be3ef5953d/server/src/eslintServer.ts#L1169-L1172

In my *lsp-log* buffer, I see this repeated many times:

TypeError: Cannot read property 'workingDirectory' of null
    at /home/adam/.emacs.d/.cache/lsp/eslint-2.1.23/unzipped/extension/server/out/eslintServer.js:1:16906
    at runMicrotasks (<anonymous>)
    at runNextTicks (node:internal/process/task_queues:61:5)
    at processImmediate (node:internal/timers:437:9)

I'm not sure if it's related, but the one thing both of these chunks of code in eslintServer seem to have in common is that they are reading from settings. So I'm wondering if there's an issue with how lsp-mode is configuring the server's settings, or something like that.

[aspiers]

OK, so perhaps I should have started with the obvious question: "is eslint really configured correct?", as I notice this seems to be specific to one or two projects. So perhaps there really is an issue with the eslint config, but when I run it from the CLI it seems fine. So how on earth can I find out what is the issue with the eslint config?

I tried enabling lsp logging, and see stuff like this:

[Trace - 12:34:30 am] Received response 'textDocument/codeAction - (25562)' in 30ms.
Result: []


[Trace - 12:34:40 am] Sending notification 'textDocument/didOpen'.
Params: {
  "textDocument": {
    "uri": "file:///home/adam/path/to/my/project/test/file.ts",
    "languageId": "typescript",
    "version": 0,
    "text": "[snipped]"
  }
}


[Trace - 12:34:41 am] Sending request 'textDocument/codeAction - (25563)'.
Params: {
  "textDocument": {
    "uri": "file:///home/adam/path/to/my/project/test/file.ts"
  },
  "range": {
    "start": {
      "line": 0,
      "character": 0
    },
    "end": {
      "line": 0,
      "character": 0
    }
  },
  "context": {
    "diagnostics": []
  }
}


[Trace - 12:34:41 am] Sending notification '$/cancelRequest'.
Params: {
  "id": 25563
}


[Trace - 12:34:41 am] Sending request 'textDocument/codeAction - (25566)'.
Params: {
  "textDocument": {
    "uri": "file:///home/adam/path/to/my/project/test/file.ts"
  },
  "range": {
    "start": {
      "line": 0,
      "character": 0
    },
    "end": {
      "line": 0,
      "character": 0
    }
  },
  "context": {
    "diagnostics": []
  }
}


[Trace - 12:34:41 am] Received request 'workspace/configuration - (2842).
Params: {
  "items": [
    {
      "section": "",
      "scopeUri": "file:///home/adam/path/to/my/project/test/file.ts"
    }
  ]
}


[Trace - 12:34:41 am] Sending response 'workspace/configuration - (2842)'. Processing request took 8ms
Params: {
  "jsonrpc": "2.0",
  "id": 2842,
  "result": [
    {
      "validate": "probe",
      "packageManager": "npm",
      "codeAction": {
        "disableRuleComment": {
          "enable": true,
          "location": "separateLine"
        },
        "showDocumentation": {
          "enable": true
        }
      },
      "codeActionOnSave": {
        "enable": false,
        "mode": "all"
      },
      "format": true,
      "quiet": false,
      "onIgnoredFiles": "off",
      "options": {
      },
      "rulesCustomizations": [],
      "run": "onType",
      "nodePath": null,
      "workspaceFolder": {
        "uri": "file:///home/adam/path/to/my/project/test",
        "name": "my-project"
      }
    }
  ]
}


[Trace - 12:34:41 am] Received request 'eslint/probeFailed - (2843).
Params: {
  "textDocument": {
    "uri": "file:///home/adam/path/to/my/project/test/file.ts"
  }
}


[Trace - 12:34:41 am] Sending response 'eslint/probeFailed - (2843)'. Processing request took 0ms
Params: {
  "jsonrpc": "2.0",
  "id": 2843,
  "result": "LSP :: ESLint is not configured correctly. Please ensure your eslintrc is set up for the languages you are using."
}

[yyoncho]

IME you will get the same error if you open that project in vscode and it all comes to project/eslint configuration. I do not have enough knowledge about JS ecosystem to help with solving that. In the past, that issue was caused by missing modules(?) in project config probably it is something like that.

[aspiers]

I tried in vscode with the extension providing the same server and couldn't see any issues. Part of the issue is that the error from emacs-lsp doesn't give any useful information. lsp-eslint--probe-failed is passed the parameters (_workspace _message) but it doesn't use either of them to help the user debug the issue. I tried adding this but _workspace was a hash which only told me the root of the project in question (I used code from describe-hash for this), and outputing _message resulted in some further error about circular references or similar.

[yyoncho]

Can you provide a sample project?

[braineo]

do you have the same server version on vscode? maybe trying C-u M-x lsp-install-server to upgrade eslint lsp?

[aspiers]

Apologies for the very slow reply, I don't recall seeing this error for a while, so perhaps it somehow got fixed during an upgrade of either lsp or the server in question. However I'll provide an update if I see it again!