Tracking issue for v0.1 release

[mrnossiom]

I'd like to go through the whole specification before the release

• to organize the codebase closer to the specification flow. It will be easier to maintain diffs.

• to update/add all proposed features

I've already reserved the name ls-types on crates.io.

Though I'd like some feedback, it seems that many would benefit from a quick v0.1 release. Going through the spec, will take a bit of time.

Parts checked

• Base Protocol
• Basic JSON Structures
  • Progress (from work done progress to partial result params)
  • everything else checked in 5098801
• Lifecycle Messages (should go into ls_types::lifecycle)
• Document Synchronization
  • text document related
  • notebook related
• Language Features
  • ...
• Workspace Features
• Window Features

Rendered diff between v3.17 and v3.18 hosted at https://lsp-diff-17-18.tiiny.site/

[Sysix]

Going through the spec, will take a bit of time.

I began the work already. For ServerCapabilities and ClientCapabalities I missed some Structs.
This issue was my last struct check. #15. Everything before should be already documented in this project.

[mrnossiom]

So I wanted to work on ls-types this week but matching the spec is really error-prone and tedious boring work.

I am considering either doing a hybrid approach where most of the structs would be generated with the provided metaModel.json but some struct implementations could be manually added to keep the control to polish library API.

This would be very close to what microsoft/lsprotocol is doing. I prefer how they translate extends by inlining fields instead of relying on serde(flatten) attributes. ORn (e.g. OR2<T,U>) to translate unions (T | U) seems annoying to use though.

See microsoft/lsprotocol#445 for possible reasons why not directly using lsprotocol (mainly about API stability and crates.io release). Also, they changed to have proposed features without a flag (microsoft/lsprotocol#435).

[Sysix]

I had the same idea with metaModel.json a while ago, but I think the documentation for the structs was missing.
microsoft/lsprotocol looks like in alpha state (from crates.io), I would not prefer to use it now.

Can we maybe have an update for both tower-lsp-community even with missing features? There were some nice changes added already from the community.
For this crate: v0.* should be always expected with breaking changes, but I would love to test it on every release, and continue on my textDocument/diagnostic integration ❤️

[dkattan]

I had the same idea with metaModel.json a while ago, but I think the documentation for the structs was missing. microsoft/lsprotocol looks like in alpha state (from crates.io), I would not prefer to use it now.

Can we maybe have an update for both tower-lsp-community even with missing features? There were some nice changes added already from the community. For this crate: v0.* should be always expected with breaking changes, but I would love to test it on every release, and continue on my textDocument/diagnostic integration ❤️

I'm also for releasing what we have for now. I think there is merit to source generating or leveraging another similar fork but man do I really want workspace/diagnostic support and to be able to advertise client diagnostic capabilities.

[mrnossiom]

lsprotocol maintainers have not answered in 3–4 months. I will try to start on what I proposed here the coming week. Here's what I have in mind more precisely:

A ls-types-gen program that takes the metaModel.json and a list of the types we want to generate/not-generate as an input. This way we can keep some amount of control for more precise types when we need to.

edit 1 → generation also makes it easier to have types behind feature flags corresponding to their version.

This should also allow unifying the traits and methods available, make types nicer to work with by embedding extends instead of using serde(flatten).

Last details related to #27, it should be possible to have a Url type that's either url::Url or fluent_uri::Uri depending on a feature flag. We might select one later, but that has been one of the major pain points that was voiced when the original ls-types project changed their Url/Uri type.

[mrnossiom]

I started a design for codegen in #29. If you have time to give a quick feedback on the design, it would be nice.