Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Include capability property path information in the metamodel #2059

Open
MariaSolOs opened this issue Nov 24, 2024 · 5 comments · May be fixed by microsoft/vscode-languageserver-node#1591
Open
Labels
feature-request Request for new features or functionality help wanted Issues identified as good community contribution opportunities
Milestone

Comments

@MariaSolOs
Copy link
Contributor

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 in textDocument.declaration (in the client's capabilities object) and similarly support in the server side is found at declarationProvider.

This information is already available in the spec's website, but for consumers of the metamodel having the capability information would be quite helpful.

@MariaSolOs
Copy link
Contributor Author

@dbaeumer if you think this is a reasonable ask I'm happy to contribute the feature in https://github.com/microsoft/vscode-languageserver-node.

@MariaSolOs MariaSolOs changed the title Include property path information in the metamodel Include capability property path information in the metamodel Nov 24, 2024
@dbaeumer
Copy link
Member

Having this type information makes sense to me.

@dbaeumer dbaeumer added the feature-request Request for new features or functionality label Nov 25, 2024
@dbaeumer dbaeumer added this to the Backlog milestone Nov 25, 2024
@dbaeumer dbaeumer added the help wanted Issues identified as good community contribution opportunities label Nov 25, 2024
@MariaSolOs
Copy link
Contributor Author

@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?

@dbaeumer
Copy link
Member

I would make that a object literal. Something like

export const capabilities: { client: 'textDocument.declaration', server: 'declarationProvider' } = { ... }

@MariaSolOs
Copy link
Contributor Author

I would make that a object literal. Something like

export const capabilities: { client: 'textDocument.declaration', server: 'declarationProvider' } = { ... }

Sounds good, thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature-request Request for new features or functionality help wanted Issues identified as good community contribution opportunities
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants