Open MariaSolOs opened 3 days ago
@dbaeumer if you think this is a reasonable ask I'm happy to contribute the feature in https://github.com/microsoft/vscode-languageserver-node.
Having this type information makes sense to me.
@dbaeumer great, I can work on it.
Before I do that though, I just want to make sure we align on the implementation. Taking protocol.declaration.ts
as an example, I plan on doing something like this:
export namespace DeclarationRequest {
export const method: 'textDocument/declaration' = 'textDocument/declaration';
export const messageDirection: MessageDirection = MessageDirection.clientToServer;
// These would be the 2 new items in the type that would be read by the metamodel generator:
export const clientCapabilityPath: 'textDocument.declaration' = 'textDocument.declaration';
export const serverCapabilityPath: 'declarationProvider' = 'declarationProvider';
export const type = new ProtocolRequestType<DeclarationParams, Declaration | DeclarationLink[] | null, Location[] | DeclarationLink[], void, DeclarationRegistrationOptions>(method);
export type HandlerSignature = RequestHandler<DeclarationParams, Declaration | DeclarationLink[] | null, void>;
}
Are you okay with this design? Are strings enough or would you prefer a more complex type to represent the capability paths?
I would make that a object literal. Something like
export const capabilities: { client: 'textDocument.declaration', server: 'declarationProvider' } = { ... }
I would make that a object literal. Something like
export const capabilities: { client: 'textDocument.declaration', server: 'declarationProvider' } = { ... }
Sounds good, thanks!
It would be helpful for the metamodel to include the property path of the respective client/server capabilitiy for each request. E.g.: The client capability for
textDocument/declaration
request is found intextDocument.declaration
(in the client's capabilities object) and similarly support in the server side is found atdeclarationProvider
.This information is already available in the spec's website, but for consumers of the metamodel having the capability information would be quite helpful.