Symfony autowiring issues since docker update

Question

I'm having autowiring issues within symfony since I have updated my Docker to the latest version.

I am not entirely sure of the causality here but certainly, my issues started appearing only after updating my docker. Since this was the case I obviously tried to revert back to a previous docker version but still had the same issues as on the new build. That's why I am doubtful of the causality.

I'm now on: Docker version 3.5.2 with Docker Engine v20.10.7

docker-engine config is the unchanged config:

{
  "registry-mirrors": [],
  "insecure-registries": [],
  "debug": false,
  "experimental": false,
  "features": {
    "buildkit": true
  },
  "builder": {
    "gc": {
      "enabled": true,
      "defaultKeepStorage": "20GB"
    }
  }
}

when I started my first project I had an issue with the composer not reading my lib-folder. This was solved as described below but it might provide some more insight, context and things I have checked/done

At first my mind went to this Windows env variable. Alas, it was set so it was not the problem. Secondly, my mind went to file ownership or file permissions but also not the problem. Everything in my containers was owned by root and had rwx permissions. Thirdly I thought it might be because of the new WSL2 backend I had to install. Until the day of the update I had still been running on the Hyper-V backend. Luckily there is a setting in docker where you can switch off the use of WSL-2 and revert to Hyper-V but this was also not the solution to my problem.

My composer.json looked like this:

"autoload": {
        "classmap": [
            "scripts/composer/ScriptHandler.php",
            "lib/",
            ...
        ],
        "psr-4": {
            ...
        }
    },

Everything but (some) files of lib were present in my autoload_classmap.php After fiddling about for too long I finally tried the following and suddenly my problems on my first project were gone

"autoload": {
        "classmap": [
            "scripts/composer/ScriptHandler.php",
            "lib/*",
            ...
        ],
        "psr-4": {
            ...
        }
    },

I still don't understand why the first one should not work. It has worked until this thursday since the infamous update.

Now on to the second project and I really can't figure out what's going on and I'm at a loss for words. My colleagues can't seem to figure out what's wrong either. This second project is something more recent so not loading a classmap anymore and everything follows PSR-4 standards.

This is the autoload part of the composer.json:

"autoload": {
        "psr-4": {
            "App\\": "src/",
            "Project\\": "scripts/"
        }
    },

This is my services.yaml (These are just the standard symfony settings AFAIK):

services:
    # default configuration for services in *this* file
    _defaults:
        autowire: true      # Automatically injects dependencies in your services.
        autoconfigure: true # Automatically registers your services as commands, event subscribers, etc.
        public: false       # Allows optimizing the container by removing unused services; this also means
                            # fetching services directly from the container via $container->get() won't work.
                            # The best practice is to be explicit about your dependencies anyway.

    # makes classes in src/ available to be used as services
    # this creates a service per class whose id is the fully-qualified class name
    App\:
        resource: '../src/*'
        exclude: '../src/{Entity,Migrations,Tests,Kernel.php}'

This is my docker PHP container:

php:
    container_name: "${DOCKER_PROJECT_NAME}_php"
    environment:
      COLUMNS: 80
      PHP_FPM_GROUP: wodby
      PHP_FPM_USER: wodby
      PHP_SENDMAIL_PATH: "/usr/sbin/sendmail -t -i -S mailhog:1025"
      PHP_DEFAULT_CHARSET: 'utf-8'
      PHP_DATE_TIMEZONE: 'UTC'
      PHP_UPLOAD_MAX_FILESIZE: '10M'
      PHP_POST_MAX_SIZE: '10M'
      PHP_DISPLAY_ERRORS: 'On'
      PHP_DISPLAY_STARTUP_ERRORS: 'On'
      PHP_MAX_EXECUTION_TIME: '30000'
      PHP_MAX_INPUT_TIME: '60'
      PHP_MAX_INPUT_VARS: '2000'
      PHP_ERROR_REPORTING: 'E_ALL'
      PHP_LOG_ERRORS: 'On'
      PHP_LOG_ERRORS_MAX_LEN: '0'
      PHP_MEMORY_LIMIT: '512M'
      PHP_SESSION_GC_MAXLIFETIME: '700000'
      PHP_REALPATH_CACHE_SIZE: '4096K'
      PHP_REALPATH_CACHE_TTL: '3600'
      PHP_XHPROF: $PROFILING_ENABLED
    env_file:
      - .env
    image: "wodby/php:7.4-dev-4.16.2"
    volumes:
      - "./:/var/www/html"
      ## For php profiler traces
      - "files:/mnt/files"

On startup I am getting the following Runtime Exception:

Cannot autowire service "App\Form\Wizard\DaysOffType": argument "$daycareTransformer" of method "__construct()" references class "App\Form\DaycareTransformer" but no such service exists.

This class is not new, it's been in code for 2 years. It's in the right folder and the namespacing is correct. Also the src folder is included in the autoload_psr4.php.

The DaycareTransformer that "can't be found" is located in src/Form under the namespace App\Form as per psr4 namespace convention

<?php

namespace App\Form;

use App\Entity\Daycare;
use App\Service\DaycareService;
use Symfony\Component\Form\DataTransformerInterface;
use Symfony\Component\Form\Exception\TransformationFailedException;

class DaycareTransformer implements DataTransformerInterface
{
    private $daycareService;

    public function __construct(DaycareService $daycareService)
    {
        $this->daycareService = $daycareService;
    }

    ...
}

There have not been any recent changes to this code. Not to the DaysOffType which has the DaycareTransformer injected and not to the DaycareTransformer.

I am the only person having these issues as I am the only one who runs Docker on a Windows machine. Production and QA environments are all up and running so there is no structural problem in the code.

Answer 1

It could be because the project running symphony in this case was locate at Windows partition (C: or D: or whatever inside your window) and not Linux distro.

If you are using WSL (most likely), you should always store Linux related project inside your distro (Ubuntu in my case, I store it it ~/...). You should not store Linux related project in /mnt/... when using WSL.

When I said "Linux related" I mean whatever project usually want to run on Linux environment, or using docker

Don't know if this could solve it for others because there could be a wide range of reason for this problem. But this is how I solve mine.

Answer 2

We've got the same problem on a Windows machine with Docker and Symfony 5.x.

We continued to work on this machine, but we changed our configuration.

For example, for your error I would use the following config.

Cannot autowire service "App\Form\Wizard\DaysOffType": argument "$daycareTransformer" of method "__construct()" references class "App\Form\DaycareTransformer" but no such service exists.

config/services.yml or config/services_dev.yml

services: 
  App\Form\DaycareTransformer: ~

We defined all the required classes from our errors and it solved our problem. But it solved problem only for one URL instead of all. You need to check each your routes or classes that use Symfony's autowire.

Unfortunately, the solution like declaration of resources didn't for us. We had to define all the required classes from our errors.

services:
  App\DataTransformer\:
    resource: '../src/DataTransformer/'

Don't redefined your classes that have already defined in your config, because it replaces your configuration and may make other errors.

You can do it in config/services.yml and commit it or you can use config/service_dev.yml and don't commit it if you haven't use this config before. In the second way you also can change .gitignore and add there the filename.

# Ignore changes for the file and don't track it. 
config/services_dev.yml

WARNING! If you still have problems with it define all the required classes in services.yml instead of two or more config files.

We don't have this problem on Linux and MacOS machines.