Server and Clients configuration

[tdroxler]

There are few little thing we could do in our plugins to improve UX, the main thing is how to find the root dir to start the server.

Currently nvim is trying to find one of: 'build.ralph', 'contracts', 'artifacts'

vscode is starting the server from the directory we launched the editor.

There's an issue with that: If you launch vscode from contracts folder, it will create there a .ralph-lsp/ralph.json and that later will compains that contracts and artifacts don't exist.

For vscode we need the same approach as nvim, to look in current and parent folders where is the "real" root dir.

The heuristic we could take in every plugin is to search in that order:

'alephium.config.ts', 'contracts', '.ralph-lsp'

If none of them is found, we use the current dir as root dir.

I also had a discussion with SDK team that artifacts is something that should be used only by the sdk, so we could remove it from our ralph.json, if we need to create some artifacts later for ralph-lsp, we could store them in .ralph-lsp

I already tested something in the improve-plugin-start branch, I hope to open a PR soon

[tdroxler]

After this comment I admit this is actually way trickier that I thought, lots of edge cases.

ralph.json file

Safety issue: Writes files outside the intended workspace directory

I re-started my thinking base on this and thought that maybe we should just not write ralph.json anywhere?

I went back to the protocol and saw that there are an initializationOptions field in the initialize request and also a DidChangeConfiguration Notification.

We can see that editors are supporting those:

• vscode
• nvim
• emacs

The next question is: Do servers actually use that for configuration? I went through some common languages and they all seem to use it, so either with the initializationOptions or the didChangeConfiguration

• nvim: python, java, typescript, cmake, c#, gradle, scala
• vscode: typescript, java, go, scala

That could be a good match for ralph-lsp specific config like dependencyPath. We have a default value so users don't need to set any initializationOptions, but if they want, they can change it from there.

Other configs, like compilerOptions could be stored in memory and changed with the alephium.config.ts.

This would remove the use of a ralph.json file and we avoid creating that file in unwanted places + it follows more the protocol.
But as always it probably introduce some downside, let's dig it

Root dir

Now the other point is how to find the root dir....

This is actually interesting and I realize I was very biased

In nvim-lsp client, every project I checked they provide a default list of file in order to find the root_dir on which to start the lsp server.
python, java, typescript, cmake, c#, go, gradle, scala

This is quite natural for me as an nvim user, I can easily go on sub directories in a project to open just the file I know, but I still want my lsp server to work at project level.

But then I couldn't find anythink like that in vscode. After a while I found this documentation of the go lsp server

In the language server protocol, a "workspace" consists of a folder along with per-folder configuration. Some LSP clients such as VS Code allow configuring workspaces explicitly, while others do so automatically by looking for special files defining a workspace root (such as a .git directory or go.mod file).

So this is actually a different approach.

Maybe vscode could start lsp-server with different settings whether there the alephium.config.ts file or not, especially regarding contractsFolder

Conclusion

Lot's of edge cases, due to different editors, different users.
We probably won't be able to cover all of them, but as long as we keep the server truely editors agnostic as now and we offer every user a way to configure there clients we should be good.

those are just my thoughts, let's open a discussion on all this.