After reading the LSP spec, it seems to me that the spec is designed so that these types can be deduced from reading the parameters.

Request (id + method)
Response (id + result / error)
Notification (method without id)

Therefore, a generic interface for them is enough

interface LSPMessage extends Message {
  id?: number | string | null;
  result?: any;
  error?: ResponseError<any>;
  params?: any
}

However, these more detailed types cannot be deduced, as we don't know if a communication is from client to server, or from server to client. Those can only be determined if you decide a perspective, such as from client side or the server side.

Send Notification
Receive Notification
Send Request
Receive Response
Receive Request
Send Response

In the docs, I'll make it clear that the log and the visualization are perspectives from the client side.

For the types, I think something like this will do:

export type LogMessageType =
  | 'send-notification'
  | 'recv-notification'
  | 'send-request'
  | 'recv-request'
  | 'send-response'
  | 'recv-response'

interface LogMessage extends Message {
  type: LogMessageType;
  timestamp: number; // Unix timestamp
  id?: number | string | null;
  result?: any;
  error?: ResponseError<any>;
  params?: any;
}

@dbaeumer What do you think?

Uh oh!

Spec JSON format for loading #7

Description

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions