Class 'MonorepoBuilder20210703\Symfony\Component\Console\Input\ArgvInput' not found in /bin/monorepo-builder.php

[jwillp]

We are currently getting this error when trying to execute the vendor/bin/monorepo-builder binary with the latest release 9.4.8:

Class  'MonorepoBuilder20210703\Symfony\Component\Console\Input\ArgvInput' 
not found in /vendor/symplify/monorepo-builder/bin/monorepo-builder.php:28

[signor-pedro]

Yeah, broke our CI too, could this be related to the fact that the v* prefixes got dropped from tagging convention?

Just speculating...

[alexbrouwer]

9.4.5 does work. I currently use "symplify/monorepo-builder": "^9.0 <9.4.6", in my composer.json. Newer versions dropped the dependency on symplify/console-color-diff which might be related?

[TomasVotruba]

This is probably due to missing downgraded /vendor directory. Based on #3292

Related repository, that should pass https://github.com/symplify/monorepo-builder

[TomasVotruba]

We're getting green again :) https://github.com/symplify/monorepo-builder

[TomasVotruba]

Btw, these were steps neccessary to fix the build:

• c17ed4c
• 03ca8c5
• 0dd02fc
• 1b42079

[TomasVotruba]

Just released https://github.com/symplify/monorepo-builder/releases/tag/9.4.10 that shoud work 👍

Big thanks to @jenkoian for initial setup of downgrade run. Apart few details it was very clean and did the most amount of work 👍

[jenkoian]

Thanks (and sorry!)

[TomasVotruba]

That's ok, It took me at least 3 months to set up first downgrade that would work :D you made it with-in a week a with rather technical glitches that you could not predict. It was fairly easy to fix.

So thank you 🙇

[signor-pedro]

Thanks @TomasVotruba.

What about the changed namespace though, are we going to get the basic MonorepoBuilder\ root back? Should I wait with upgrade until the namespaces "stabilize"? 😅 Thanks for your answer

[TomasVotruba]

@signor-pedro Hey. What do you need the namespace for? :)

It can be ommited from scoping like this in ECS:
https://github.com/symplify/symplify/blob/17854e006bf4755db9b9bc658df42b75a5e25fd5/packages/easy-coding-standard/scoper.php#L34-L36

Here is scoping configuration for MonorepoBuilder that needs to be updated:
https://github.com/symplify/symplify/blob/main/packages/monorepo-builder/scoper.php#L24

[signor-pedro]

@TomasVotruba Thanks for the reply, I am not really sure I understand the whole php-scoperthing.

What I do is simply install monorepo-builder via composer as described in README.md.

It all worked fine until a couple of days ago, when our CI pipeline broke on static analysis (we're using psalm to perform analysis).

Psalm is not optional in our pipeline (psalm failing = no deploy), as it helps us catch a lot of bugs.

Now the question is, whether I can expect the namespace to become once again MonorpoBuilder\, or whether I should re-design our pipeline :)

Sorry for bothering you with my 0 knowledge on this subject :)

[TomasVotruba]

I see, thanks for sharing :)

[TomasVotruba]

Should be fixed in 3302afd

[signor-pedro]

Great, many thanks!

[TomasVotruba]

Damn... one more issue https://github.com/symplify/monorepo-builder/runs/2998396258

[TomasVotruba]

Allright, now it's green :) symplify/monorepo-builder@8ace2be

Could you verify the version is running ok?

[signor-pedro]

@TomasVotruba sorry to bother you but the pipeline is still red 😢 even on 9.4.12.

One thing that has changed is that PHPStorm now recognizes the namespace - the use statement is no longer saying "Class does not exist".

However, now PHPStorm complains that some polymorphism requirements have not been met:

PHPStorms suggests this fix:

It does seem that even if the ReleaseWorkerInterface is recognized, it internally hard-codes method arguments to prefixed namespaces.

Psalm still complains that Class, interface or enum named Symplify\MonorepoBuilder\ValueObject\Option does not exist etc.

Sorry for the bad news, I know OSS is harsh, I can hard-code our dependency on 9.4.5 until you have some more time to fix this - no stress.

[signor-pedro]

P.S. if the dynamic namespace resolution is the way you want to go from now, and psalm has a problem with that, I can just exclude the whole monorepo-builder.php from static analysis - there is a very little chance someone will introduce type-related bugs there.

I am "out-of-context" and don't see the reasons for why you are doing prefixed namespaces - but you are the architect, it's your choice ;) I can adjust

[TomasVotruba]

sorry to bother you but the pipeline is still red cry even on 9.4.12.

No problem. Could you try dev-main? The nersion is not tagged yet.

However, now PHPStorm complains that some polymorphism requirements have not been met:

I see. The Version class is part of public API, we should unprefix it too - daed54b

Psalm still complains that Class, interface or enum named Symplify\MonorepoBuilder\ValueObject\Option does not exist etc.

I think other tools don't have an acess to MonorepoBuilder' autoload. It has own vendor that is accessible only in vendor/bin/monorepo-builder - https://github.com/symplify/monorepo-builder

[TomasVotruba]

I am "out-of-context" and don't see the reasons for why you are doing prefixed namespaces - but you are the architect, it's your choice ;) I can adjust

The reason for scoping is installation for older projects. Let's look at a case without prefixing & downgrading:

composer require symfony/console 4.4
# php 7.4

composer require symplify/monorepo-builder
# error: symplify/monorepo-builder requires PHP 8, symfony/console 5.4

With prefixing on the other hand, you don't care about this:

composer require symfony/console 2.8
# php 7.1

composer require symplify/monorepo-builder
# of course :)

[TomasVotruba]

P.S. if the dynamic namespace resolution is the way you want to go from now, and psalm has a problem with that, I can just exclude the whole monorepo-builder.php from static analysis - there is a very little chance someone will introduce type-related bugs there.

I'm affraid that is need for any static analysis tool... or you can include the autoload file there.
I know PHP_CodeSniffer has own autolaod too and if we need it in PHPStan, we have to include it :)

E.g. like this:

# phpstan.neon
parameters:
    bootstrapFiles:
        - vendor/squizlabs/php_codesniffer/autoload.php

[TomasVotruba]

This might explain the dependency issue better:

composer.json Before Scoping

composer.json After Scoping

[TomasVotruba]

I've extended my comment and know-how behind these scopings to 2 posts :)

• Why do we Scope PHP Tools
• How to Scope Your PHP Tool in 10 Steps

cc @jenkoian, in case you'd like to scope another package, this will give you more exact steps to rely on 👍

[jenkoian]

Thanks @TomasVotruba! Interested in your thoughts on this versus the kind of approach PHP CS Fixer suggests i.e. a 'scoped' directory for each tool.

I guess, the scoper tool comes in particularly useful when you need to use the vendor classes within your code and thus need to use the same autoloader, rather than just have a tool 'act' on your code.

[TomasVotruba]

Hi, that is like renaming vendor to a diferent vendor-extra directory. The problem is still there just in a nother directory.

It's a cheaper solution if scoping is too hard (the tooling is very weak, I often gave it up and used some hack), but in the end it brings more problem. Like multiple vendor with same class etc.

[signor-pedro]

@TomasVotruba thank you very much for your effort.

I just got back from my 3-week vacation, I will let you know in the next couple of days if the latest version passes on our CI.

Also, thank you for writing up about the prefixing!

[TomasVotruba]

Thanks for reaching out 🙂 👍 I hope you're fresh and well rested 💪