Another LSP serialization bug

Bug Reports
#1

I have a piece of code that uses the LanguageClient to send a request that takes an array for it’s parameters.

Nova mangles this… I am sending ["x86_64"] (for example), and here’s what Nova mangles it to:

Serve-D[20:42:50.869000] Sending JSON-RPC request: number(4) served/switchArchType
{
  "jsonrpc" : "2.0",
  "id" : 4,
  "method" : "served/switchArchType",
  "params" : {
    "0" : "x86_64"
  }
}

My LSP (which I am not the author of, it’s someone else’s work) can’t cope with this. It expects an array of strings. (Arrays are perfectly legal JSON-RPC types.)

Between this, and the mangling of numeric 0 and 1 into true/false, I’m finding a lot of unfortunate friction trying to make full use of the LSP.

Perhaps a workaround would be to give an API where we can send a string (which I can create with JSON.stringify) that is sent instead? (Or alternatively, WHY for the love of all that is good doesn’t Nova just use JSON.stringify and send that?)

#2

Hello Garrett,

Thank you for your report. I’ll file this as something we need to look into investigating.

(Or alternatively, WHY for the love of all that is good doesn’t Nova just use JSON.stringify and send that?)

Sending and receiving LSP methods is done from Nova’s native code. Only extension code is implemented in JavaScript. When your parameters have reached the point where they are encoded as part of a JSON-RPC message it is on the other side of the native-to-JS bridge, and that method isn’t applicable.

1 Like
#3

Yes please. Fixing this, and the other serialization bug (true/false) will eliminate some serious problems I’m trying to workaround.

#4

So it looks now like this is fixed as well. Huzzah!