[config-transformer] Cannot autowire service "Migrify\ConfigTransformer\Converter\ConfigFormatConverter"

[GenieTim]

Wanting to convert https://github.com/matteosister/GitElephant/blob/ffe22770bf43e755dce7cce892275bf11b8b0041/ecs.yaml to PHP using https://github.com/symplify/config-transformer leads to an error when following the README's instructions.

Steps to reproduce:

1. Download repo: git clone git@github.com:matteosister/GitElephant.git (assuming git is available.)
2. Install dependencies: composer install (assuming PHP & composer are installed)
3. Follow config-transformer's instructions:

• composer require symplify/config-transformer --dev
• vendor/bin/config-transformer switch-format ./ecs.yaml

If you are from the future, in between steps 1 & 2, you might want to switch to the commit I am currently at using git checkout ffe22770bf43e755dce7cce892275bf11b8b0041.

Then, I get the following error:

[ERROR] Cannot autowire service "Migrify\ConfigTransformer\Converter\ConfigFormatConverter": argument                  
         "$yamlToPhpConverter" of method "__construct()" references class "Migrify\PhpConfigPrinter\YamlToPhpConverter" 
         but no such service exists.                       

[TomasVotruba]

Hi,

this package has been recently migrated and not stable-tagged yet.

Currently you're using old code, as there is no Migrify\\ class use in the package.

Be sure to use @dev version in your composer.json:

{
    "require-dev": {
        "symplify/config-transformer": "@dev"
    }
}

[GenieTim]

Hi, thank you for the fast response. This indeed solved the problem. For anyone else, the following steps were necessary:

• change "minimum-stability" in composer.json from "stable" to "dev"
• change version of "simplify/config-transformer" to "dev-master"
• run composer upgrade --with-all-dependencies -W
• (do format switching, potentially with manual interventions)
• change "minimum-stability" in composer.json from "dev" back to "stable", remove "simplify/config-transformer" as dependency

[c33s]

@TomasVotruba how is this supposed to work on older projects?

• according to this ticket stable is broken
• @dev does not install anything other than *
• @dev with minimum-stability: dev installs quite a lot of dev packages
• phar file with its own dependencies is not an option for you, see #2743
• dev master requires php 7.3+
• dev master also requires symfony symfony/dependency-injection ^5.2 what about symfony lts?

am i doing something wrong or is the only way to migrate configs of older projects, to create a new symfony 5.2 project with php 7.4, copy the yaml configs there and copy the php configs back in the project? is it really necessary to have such high version requirements (both symfony and php)?

also tried to install it globally with https://packagist.org/packages/bamarni/composer-bin-plugin (as i get conflicts otherwise) but then i still get

config-transformer switch-format config -i yaml -o php

 ! [NOTE] Processing "config/app/easy_admin/design.yaml" file                                                

 ! [NOTE] Processing "config/app/easy_admin/entity/login_user.yaml" file                                     

 ! [NOTE] Processing "config/app/easy_admin/entity/news.yaml" file                                           

 ! [NOTE] Processing "config/app/easy_admin/entity/person.yaml" file                                         

 ! [NOTE] Processing "config/app/easy_admin/entity/personGroup.yaml" file                                    

 ! [NOTE] Processing "config/app/easy_admin/entity/publication.yaml" file                                    

 ! [NOTE] Processing "config/app/easy_admin/entity/publicationType.yaml" file                                
...
...
  Expected to find class "App\Controller\NewsController" in file "myproject\src/Controller\NewsController.php" while importing services from resource "../src/*", but it was not found! Check the namesp
  ace prefix used with the resource.

should it be possible to install it globally?

[TomasVotruba]

In this case, there are 2 ways to solve it:

• build a scoped version to avoid conflicts, as ECS has
• use static reflection like PHPStan, see https://github.com/rectorphp/rector/pull/5665

[c33s]

please don't get me wrong, i really appreciate your effort, i always read your blog and also changed some of my coding behavior according to your suggestions. thanks for that. i think you are a very good coder. i only try to give feedback even if it is inconvenient. hope my writings don't make me lose the opportunity to meet you some day and have some nice discussions while having a drink.

as you might imagine i am quite unhappy with the current situation of this tool. if we don't look at this tool as an opensource tool where you simply share code which you made for yourself for free with the community this text would end right here with the words "thank you for your work, sadly it doesn't fit my needs but keep it up". if we take a few steps back and look at it as a tool which should make things easier and be helpful, the UX/DX (user/developer experience) is really not good (really sorry for saying that. again please don't get me wrong).

in the end it's a tool which should convert yaml config to php comparable to json2yaml from caltechs datatools. it's like you say:

no, you can't convert this json file to yaml with a standalone version of this tool, you have to install this converter as dependency of your go project but your go project has to use the version x of go. and by the way, it also requires you to change one other dependency of your project to the version y. to overcome this you can compile it in a special way you have never done before.

you can also play this game with a hammer and no, you can't put your nail in, you need a nail version 2.0 and of course you also need wall 4.0, so you can't use the hammer in your house.

does that really fit to your libaries mantra of "simplify"?

my usecase was to slowly migrate a symfony1 (yes one) project running on php 5.6 to symfony3 to pave the way to migrate it later to symfony4.4 on php7.4. one step would have been to use php configs from the start but sadly there are not so many examples of more complex php configs out there, so your tool looks like it is the right choice but i can't even use it on my most current projects which are symfony4 on php 7.4 without quite a lot of effort.

again i fully understand if you say "i have no time for that and i don't care" as of course all the work you are doing here is for free (thanks for that), i just wanted to give you some insights on how your tool could have been used and how some decisions of you simply block it from really being used. have a look at composer which still has quite low php version requirements and works as phar.

i really hope to see all or some of the following features in your tools

• standalone phar support (as phpstan, phpunit, php-cs-fixer)
• lower php version support
• lower symfony support (at least symfony4.4)
• out of the box prefixed or static reflection (didn't have a look at what this exactly is yet. just listed it here because you wrote about it) version

[TomasVotruba]

Hi, thanks for sharing that.

I basically don't have time for more free work here, as I fully focus on @rectorphp and private clients. The more people use Rector, the more crappy code it has to be to handle it :) quite a challange. E.g. see https://github.com/rectorphp/rector/pull/5665 for my open-source work for this week. Took 30-35 hours in total.

But I'd be happy to merge pull-request, if you decided to contribute Symplify. Your idea are valid and if I would come across the same problem, I'd solve them as you suggest :+1: