JSON-Parsing error that prompts the workspace to be restarted endlessly

tmythicator commented 3 years ago

Thank you for the bug report

[X] I am using the latest version of lsp-mode related packages.
[X] I checked FAQ and Troubleshooting sections
[ ] You may also try reproduce the issue using clean environment using the following command
```
emacs -q -l lsp-start-plain.el
```
where lsp-start-plain.el can be downloaded here. Alternatively, it will be great if you can reproduce the issue using lsp-docker which provides the minimal configurations for lsp-mode and ships with most of the language servers.

Bug description

I am currently working on a large codebase, where on most modules/directories the LSP-client starts without problem and offers functionalities. So I am using multiple workspaces.

But there is one workspace that throws an error almost immediately after successful initialization. After that it prompts for the workspace restart, but this doesn't improve the situation.

Steps to reproduce

Cannot provide with sample file/project because of sensitive information

Expected behavior

Should work without problems

Which Language Server did you use?

lsp-typescript

OS

MacOS

Error callstack

Error in *Messages*:
`LSP :: Error from the Language Server: Request textDocument/documentSymbol failed with message: navtree timeout (Internal Error) [5 times]`

Contents of stderr-buffer:
`Process ts-ls stderr<1> finished
(node:74068) UnhandledPromiseRejectionWarning: Error: geterr timeout
    at Timeout.<anonymous> (/usr/local/lib/node_modules/typescript-language-server/lib/utils.js:25:25)
    at listOnTimeout (internal/timers.js:554:17)
    at processTimers (internal/timers.js:497:7)
(node:74068) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag --unhandled-rejections=strict (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 1)
(node:74068) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.
undefined:1
<--- Last few GCs --->
^

SyntaxError: Unexpected token < in JSON at position 0
    at JSON.parse (<anonymous>)
    at TspClient.processMessage (/usr/local/lib/node_modules/typescript-language-server/lib/tsp-client.js:108:30)
    at Interface.<anonymous> (/usr/local/lib/node_modules/typescript-language-server/lib/tsp-client.js:57:56)
    at Interface.emit (events.js:314:20)
    at Interface._onLine (readline.js:329:10)
    at Interface._normalWrite (readline.js:474:12)
    at Socket.ondata (readline.js:186:10)
    at Socket.emit (events.js:314:20)
    at addChunk (_stream_readable.js:297:12)
    at readableAddChunk (_stream_readable.js:272:9)

Process ts-ls stderr<1> finished`

Anything else?

VSCode handles it without problems

yyoncho commented 3 years ago

Steps to reproduce

Cannot provide with sample file/project because of sensitive information

You can try to narrow down a reproducer without sensitive information?

tmythicator commented 3 years ago

I would do my best, but it may take quite a time

tmythicator commented 3 years ago

I got the problem fixed. The issue was that on specific folders of the project (e.g. the folder, where all jasmine tests are located) there was no hint for LSP client, which webpack configuration to use.

So for example, if you have the tsconfig.json stored in ~/myProject/webpack/tsconfig.jsonand there are some folder, like ~/myProject/app-test/jasmine/test/app/uiwhere all the testing files are located, you need to manually add another tsconfig.json file like that:

{
    "extends" : "../../../../../../webpack/tsconfig.json",
    "include" : [
        "**/*"
    ],
    "exclude" : [
        "node_modules"
    ]
}

It looks like VSCode guesses the tsconfig.jsonwithout this extra file. It would be nice, if VSCode would guess that good as well. Should we make a feature request for it?

yyoncho commented 3 years ago

It looks like VSCode guesses the tsconfig.jsonwithout this extra file. It would be nice, if VSCode would guess that good as well. Should we make a feature request for it?

make sense.

Marking as closed since it seems like there is nothing we can do on lsp-mode side(reopen if you disagree).

emacs-lsp / lsp-mode