PhpStorm cannot find autoload.php in Docker container under WSL2

Docker for Windows has recently improved by utilising the WSL2 backend rather than Hyper-V. The performance gains with this are big, and seeing as I use Windows as my main dev environment, wanted to utilise this myself so made the swap.

I'm primarily a PHP developer, and my IDE of choice is PhpStorm. This in itself works fine, but I encountered a problem when trying to run my PHPUnit tests. The problem is, is that the autoloader.php file doesn't get mounted into or mapped to the PHPUnit container, meaning that the test suite always failed.

This isn't an issue when developing a site where you likely have a PHP container with everything combined (including PHPUnit), so when you run PHPUnit in that case, autoloader.php is already mounted along with the vendor dependencies and everything works as expected, but when you're trying to develop a package for example, where you don't have a complete Docker Compose environment up and running, this causes a problem... but it also lead me to a workaround solution.

You can create a lean docker-compose.yml file definining just a PHP container (I use a custom built container with the dependencies that I need already built in, it's the same one I use for developing full-blown sites with):

version: "3.7"

services:
  php:
    container_name: pkg
    image: my.private.registry/php7-cli:7.4.10
    volumes:
      - ./:/opt/project
    entrypoint: /bin/bash
    tty: true

You can then spin this container up in the WSL2 console:

docker-compose up -d

The configuration within PhpStorm is then the same as you'd configure for a full-blown site development.

When selecting a remote CLI interpreter, select Docker Compose and select your service:

In the CLI Interpreter settings, choose Connect to existing container:

In test frameworks, select the remote interpreter we just configured and PHPUnit will show up:

Finally, run the test suite, sit back, and enjoy the fruits of your labour =)

It's a hacky method, especially when creating the likes of packages when you don't need a service running like you would with a site, but for now at least it's usable and you gain the performance benefits of WSL2 rather than Hyper-V backends.