You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As mentioned here, it would be great to refactor the extension and LSP server. Here are some ideas to consider; please feel free to raise other points or challenge any listed:
Use promises in the LSP server, as many endpoints spin a binary or read files.
Refactor incrementalCompilation.ts and implement an interface to handle the differences between bsb and rewatch, as those checks are scattered throughout the code.
At some point the server part should be in OCaml (#269).
Then we only have a small client left where we could get rid of the typescript dependency entirely. The client might not be too much work to rewrite in ReScript instead?
At some point the server part should be in OCaml (#269).
True, but all the above are feasible. I started working on an OCaml LSP some time ago: https://github.com/nojaf/rescript/tree/lsp. It is a lot of work, and I became a bit demotivated upon learning that the analysis-tool currently relies on being run as a single execution. During the retreat, there was also mention of possibly doing this in Rust. I'm not sure which option is the lesser evil, though.
We probably want to switch from TextDocumentSyncKind.Full to TextDocumentSyncKind.Incremental (see "Incremental Text Document Synchronization" from the language server extension guide) and use VS Code's TextDocuments documents manager instead of rolling our own file content cache as we currently do.
Activity
fhammerschmidt commentedon May 16, 2025
At some point the server part should be in OCaml (#269).
Then we only have a small client left where we could get rid of the typescript dependency entirely. The client might not be too much work to rewrite in ReScript instead?
nojaf commentedon May 16, 2025
True, but all the above are feasible. I started working on an OCaml LSP some time ago: https://github.com/nojaf/rescript/tree/lsp. It is a lot of work, and I became a bit demotivated upon learning that the
analysis-toolcurrently relies on being run as a single execution. During the retreat, there was also mention of possibly doing this in Rust. I'm not sure which option is the lesser evil, though.nojaf commentedon May 16, 2025
Yeah, that could be fun to have in the end.
mediremi commentedon May 16, 2025
We probably want to switch from
TextDocumentSyncKind.FulltoTextDocumentSyncKind.Incremental(see "Incremental Text Document Synchronization" from the language server extension guide) and use VS Code'sTextDocumentsdocuments manager instead of rolling our own file content cache as we currently do.