Introduce an option of dump-autoload to fail on PSR uncompliant classes

[Kolyunya]

I would like to suggest adding an option to the dump-autoload command which would force it to fail when it encounters PSR uncompliant classes. This would be very profitable to add this kind of validation to the CI scripts.

Currently, the command just prints to the stdout notices like the following but the return code is always 0 thus there's no straightforward way to automate this important validation process.

Class Foo located in ./Foo.php does not comply with psr-4 autoloading standard. Skipping.

[Seldaek]

This is really not so trivial to add IMO.. So sounds like not really worth the trouble to me.

I think it could be done by propagating a list of warnings all the way through AutoloadGenerator::dump and its children and into ClassMapGenerator too, so that DumpAutoloadCommand could easily retreive warnings and exit differently if --strict is passed in for example.

[temp]

@Seldaek maybe introduce a validate-autoload command? We would like to check for this is in our ci-pipeline, but don't want to parse a dump-autoload run...

[danepowell]

Agreed, and I'd like to see this option anywhere that a warning can be generated. For instance, you can get the PSR-4 warnings on composer install as well. It's hard to have bulletproof CI when problems like this can't be caught.

[Seldaek]

Yeah I got a possible solution in the works - hopefully can wrap this up next week

[Seldaek]

See #10886

[Kolyunya]

@Seldaek thank you so much for your work! Looking forward to a stable release to test it out!

[Seldaek]

You can give it a shot with "composer self-update --snapshot" already

[danepowell]

Thanks! We've already implemented this in our CI to catch tests with bad class names that Composer would otherwise fail to load: acquia/cli#1070