polyfill-php72 | This component provides functions added to PHP 7.2 core | Web Framework library

That composer.json file is a bit of a mess. Some Symfony packages on 5.3, some even on 5.1, and many on 6.

Also you are controlling Symfony versioning from extra.symfony.require, and at the same time from the discrete version constraints. You include some packages that no longer exist on 6.0 (symfony/security-guard), and are missing some that should be installed on a 6.0 version.

It's simply not on an installable state.

I've managed to make it installable changing it like this:

I have had this error when using symfony server:start with docker inside a php-alpine container. Each time i run migrations or doctrine:schema:update in a fresh installed instance, my symfony local web-server would throw error: issue with server callback error="unable to fetch the response from the backend: malformed MIME header: missing colon: "FROM information_schema.schemata I solved it by dropping the alpine container and building everything from the FROM ubuntu:20.04 image: i had to install php, drivers and all dependencies too. This did not go well with my production env because the image was above 1GB, meaning it had binaries i did not need in production. From experience the symfony local web-server needs a python environment but am not sure on that.

After some days, i stumbled on this git repository: https://github.com/dunglas/symfony-docker. which is recommended from Symfony docs here: Using Docker with Symfony. It uses caddy as the web-server. I learnt from it, tweaked to suit my needs and from then never used symfony local web-server. Its a good project, kudos to Kévin Dunglas and maintainers. The php image is about 200MB. Caddy too is about 40MB. Great for both prod and dev environments.

Please peruse the repo and adopt what you can or everything.

Disclaimer: This is not an answer to your problem/error, but an easy alternative.

Please have a look at the documentation of Composer scripts. It explains pretty obvious:

post-install-cmd: occurs after the install command has been executed with a lock file present.

If you are using composer install with a lock file not present (as indicated from the console output), this event is not fired.

The solution is to execute:

You have conflicting requirements.

On extra.symfony.require you say you want 5.3.*.

But on your individual Symfony requirements you are specifying either ^5.2 or 5.2.* (and in some cases ^5.3 as well).

When a project uses Symfony Flex (as is your case), the presence of extra.symfony.require will be used to restrict what package versions to install for many/most Symfony packages. But only if you do not declare a specific version on your require section.

In this case, you are already specifying a version on the 5.* range on extra.symfony.require. Leave that one like that, and just use * as a version constraint for all the other Symfony Packages in the require section.

(Note that's it's not really all, since some packages are not managed by Flex, just update the ones that have versions declares in the 5.* range)

Deleted vendor directory. Ran composer install. Noticed message after installation

As you can read in an issue posted in the issue tracker of doctrine/cache, that class has been deprecated in v1 of that package, and removed in v2.

If you still want to use that class, run composer require doctrine/cache "^1.12" to install a version of that package from the v1 branch.

On the long run, you should check where your application requires that class and search for alternatives. If you need help with that, please share more details.

This is actually a somewhat interesting edge case.

The bottom line is that autowire is defining your controller service as private. This in turn means the controller resolver is simply new'ing the controller instead of pulling it from the container. Hence the missing argument error messages.

Notice that your controller does not extend AbstractController. If it did then autoconfigure would know that it is a controller and end up making it public. All would be well.

Prior to 5.3, the services.yaml file contained:

Since you are not installing the "bundle" using composer, the autoloader does not get generated, and the class pertaining to your new package will never be found.

The bundle's composer.json file is irrelevant, since again, you are not installing the package through composer. Thus, it's never read.

But you can instruct composer to generate autoloader files that take this new bundle into account.

Let's say that this is your directory structure: