Move VS Code extension into compiler repo

[cknitt]

Move the VS Code extension sources from https://github.com/rescript-lang/rescript-vscode into the compiler repo so that they can be maintained together and binary compatibility is ensured (see e.g. #6979 (comment)).

[fhammerschmidt]

Sidenote: At some point the repo should probably just be called ReScript, or something else, because it is much more than just a compiler now.

[cometkim]

The VSCode extension doesn't seem to be monorepo friendly.

https://code.visualstudio.com/api/references/extension-manifest#marketplace-presentation-tips

[cometkim]

IMHO it would be better to integrate the LSP feature into the compiler and leave the VSCode extension itself external.

[nojaf]

This is how gleam does it. You install it and their cli has a command to start the lsp server.
All logic happens there and you have thin clients that connect to it.

[nojaf]

I have one question: Currently, the LSP tooling calls OCaml components externally. These tools read artifact files from the lib folder. It's somewhat fortunate that this setup works as it does. If the compiler generates slightly different *cmt files, for example, the tooling could potentially break. So, having the LSP server integrated into the rescript command would be ideal to ensure that the tooling always runs on a compatible version, right?

[zth]

@nojaf that's the gist of it yes. Essentially, whatever works on the compiler artifacts is what's in danger of breaking. That's currently the thing we call analysis, which is an OCaml program that drives most of the editor tooling functionality. tools is another thing which operates on these files.

The language server itself isn't that important to move, but mid to long term the goal is to integrate that into the compiler repo and ship something like a command (rescript lsp) that starts a language server dedicated to that particular project + compiler version.

We still have to worry about all existing compiler versions that doesn't ship with its own language server. So, the current extension and analysis will need to remain in some form, regardless of whether we ship the compiler stuff. But that's a minor issue, we could hide that fairly well, and it'd rarely be updated.

That has been my worry mostly, that we've been working so actively on the editor tooling and that locking improvements down to compiler versions means people on older versions don't get access to the improvements. But slowly we're getting to a state where that's more acceptable.

[nojaf]

I believe v12 is a perfect opportunity to introduce rescript lsp. Users on older versions can continue using the current VSCode plugin. While it's a commendable goal to support all versions of ReScript with a single plugin, we should keep in mind that most of this work is done by volunteers in their spare time. Therefore, I wouldn't be too hard on myself for not supporting older versions any longer.

Additionally, providing new tooling benefits could motivate users to upgrade to the latest version of ReScript.

[cknitt]

OCaml sources (tools, analysis) were copied to the compiler repo.

The JS part stays in the extension repo.