We currently have a Language Server for Darklang written in Node — this powers our (WIP) VS Code Extension.

This Node server acts as an intermediate server, calling upon Darklang code to indirectly support the Extension, via the darklang-cli -- starting, running, and exiting the executable for every request the LSP client/extension makes. (e.g. for every re-evaluation of name resolution of parsed Darklang source code)

Some problems with the current approach:

• it’s slow - both speed and latency are poorly impacted by this extra server
• extra types and to deal with the in-between server communicating in both directions, and sort of a general hassle in dealing with the extra Node stuff
• doesn't really move darklang CLI runtime forward
• won’t let us fully edit the LSP within the Extension itself, once the Extension works
• (some minor setup code to build the server)

At some point, we should delete this Node LSP server in favor of one written in Darklang, which will probably be sitting on top our CLI runtime. Is that time now/soon? This document covers the steps I think in our way to discuss+decide this, I think "in order.” (not to say we shouldn't pursue multiple of these at the same time

Alternative set of JSON parser+serializer fns

Long-Living Darklang CLI

Support of JSON-RPC

Support of LSP Server Spec

Implement the Dark LSP Server in Darklang

Tangential/Later

Elmish-CLI

• unblocked now that now that the multi-input CLIs work