Map LSP paths

[weirdan]

Allows mapping of paths passed over LSP protocol. This is useful where you need
to run Psalm language server inside a container where project paths differ from
those on host machine.

Partly addresses #6919 (for LSP only)

[weirdan]

4.x branch is closed now as we prepare for the 5.0 release. Please target the master branch instead.

[orklah]

On your own PR :D nice!

[orklah]

Closing as this targets 4.x which is closed. Please reopen on master going forward

[m-graham]

@weirdan are you planning on targeting the master branch with your original merge request?

[weirdan]

@m-graham are you using this branch?

[m-graham]

Hi @weirdan,

I work from within a dev container and realized after sending my previous message that I could still use the VSCode plugin by specifying that it uses a TCP connection.

I'm not actively using this branch.

[weirdan]

@tm1000 as our LSP expert, do you think it would be better to use the following approach instead?

1. Capture rootUri sent from the client (we do not support multiple workspace folders)
2. Assume the server cwd in the container is the same directory as rootUri on the host machine (e.g. if we're running in /var/www/ folder in the container and received rootUri: file:///home/weirdan/src/myproject, it means /home/weirdan/src/myproject folder on the host machine was mounted as /var/www into the container).
3. Having both of these pieces of info use them to translate between /var/www/src/filename.php and file:///home/weirdan/src/myproject/src/filename.php when communicating with the client.

This works for me with my local patched Psalm, and has an added benefit of not requiring any configuration.

[tm1000]

1. Capture rootUri sent from the client (we do not support multiple workspace folders)

So technically I think we could support multiple workspace folders from the extension but it would just launch separate Psalm instances for each workspace. Thus I think what you propose still works

This works for me with my local patched Psalm, and has an added benefit of not requiring any configuration.

So I think this works. The way I'm doing it now for all of my docker containers is I actually have psalm running outside of the container so it runs locally on the system. I'm not saying that works for for everyone. But that way I dont run into docker networking issues like this.

I like that you don't have to configure anything but I believe someone out there will want/need to be able to configure that. Is it possible to allow that? I think bare minimum it needs to be configurable, not that they need to change it from day 1

[weirdan]

we could support multiple workspace folders from the extension but it would just launch separate Psalm instances for each workspace.

I believe that's already the case, see psalm/psalm-vscode-plugin#184

I believe someone out there will want/need to be able to configure that. Is it possible to allow that?

Possibly. I'm wouldn't go with the config file approach (as in this PR) though, it's too much hassle to set up for end users. The way I see it, it would be limited to LSP use case, so either a CLI switch (e.g. --map-folder=/home/weirdan/src/project:/var/www/) or LS initialization options entry (received during initialize request in InitializeParams.initializationOptions element). CLI switch looks like it would be easier to implement both on the server and client side.

This won't immediately allow running Psalm in Docker containers with psalm-vscode-plugin though. Unlike some other plugins that just allow one to specify the command to execute, with psalm-vscode-plugin it's not possible to specify something like docker-compose exec -T php php -dmemory_limit=-1 vendor/bin/psalm-language-server --verbose.

[tm1000]

we could support multiple workspace folders from the extension but it would just launch separate Psalm instances for each workspace.

I believe that's already the case, see psalm/psalm-vscode-plugin#184

Oh. and I merged it too! I forgot

I believe someone out there will want/need to be able to configure that. Is it possible to allow that?

Possibly. I'm wouldn't go with the config file approach (as in this PR) though, it's too much hassle to set up for end users. The way I see it, it would be limited to LSP use case, so either a CLI switch (e.g. --map-folder=/home/weirdan/src/project:/var/www/) or LS initialization options entry (received during initialize request in InitializeParams.initializationOptions element). CLI switch looks like it would be easier to implement both on the server and client side.

The CLI switch is fine as usually most of those I then store in the Configuration class in the LSP itself which means they are easily changeable on the fly from vscode (or other LSPs)

This won't immediately allow running Psalm in Docker containers with psalm-vscode-plugin though. Unlike some other plugins that just allow one to specify the command to execute, with psalm-vscode-plugin it's not possible to specify something like docker-compose exec -T php php -dmemory_limit=-1 vendor/bin/psalm-language-server --verbose.

Yes this is true it will require additional settings as I have seen in a few other plugins/extensions. I will work on that in the upcoming weeks along with sending configuration now that we support that in the LSP itself

[weirdan]

Superseded by #10033