Configuring Remote (WSL) Composer in PHPStorm
I'm trying to configure a PHPStorm project to utilize both remote PHP and a remote Composer. Remote being my Windows Subsystem for Linux (WSL) installation. However, when I initiate any Composer commands from PHPStorm, I get errors. And unfortunately, the errors are not very indicative of the cause or offer a link for additional details.
Errors received in my "Event Log":
12:21 PM Composer
Failed to install packages for ./composer.json.
Show in Log
And in my "Composer Log" when I click on "Show in Log" above:
install --no-interaction --no-ansi
/bin/sh: 1: composer: not found
Failed to install packages for ./composer.json.
So far, I've followed the instructions located at:
https://www.jetbrains.com/help/phpstorm/how-to-use-wsl-development-environment-in-product.html
and
https://www.jetbrains.com/help/phpstorm/configuring-remote-interpreters.html
I also followed the answer at this post to set WSL as my default terminal:
How to use WSL as default terminal in WebStorm or any other JetBrains' products?
In my WSL installation, composer is located at /home/<user>/.local/bin/composer and is included in my path upon login in my /home/<user>/.profile file. And I was sure to restart PHPStorm after doing so to ensure it has the updated path. Additionally, running composer install within my project, on WSL works without issue.
I'm not sure how to determine which terminal or composer file PHPStorm is using. Either it's still trying to find and use a composer on my host Windows install (which doesn't exist) or I'm missing a path which I have to map for WSL.
Any idea how I can obtain additional details as to what might be misconfigured?
Please sign in to leave a comment.
I figured out my issue.
When in Settings -> PHP -> Composer, in the "Execution" section. I was already selecting "Remote Interpreter", but the "Composer executable" field requires an absolute path. I was simply supplying the name of the executable since the field is asking for the executable.
I just figured it would utilize my $PATH to resolve the executable, but this isn't using an SSH session so it wouldn't have my custom $PATH values. So it all makes sense.