Open tdroxler opened 1 month ago
After this comment I admit this is actually way trickier that I thought, lots of edge cases.
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:
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
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
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
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.
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 thatcontracts
andartifacts
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 ourralph.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