This is work-in-progress PR. Here is a related issue: https://github.com/Symplify/Symplify/issues/1118.

I have several questions on how to better proceed further.

1. ~How to dynamically select which output formatter to choose. I tried to access ArgvInput, but couldn't find passed options. Still need to figure out how to extract OutputFormatterFactory from CheckCommand.~

2. ~What way of outputting data is better. Still thinking what way is better, since some errors are fixable some not.~

3. ~I don't know yet how to turn off every other output once --output-format=json is set. This way it will allow other programs to consume output directly since it will be pure json. Probably isVersionPrintedElsewhere() is responsible.~

4. ~Should I add --pretty flag for json? Why would anyone need a human readable output in json?~

5. ~$this->errorAndDiffCollector->getFileDiffs() and $this->errorAndDiffCollector->getErrors() as I understood do different things. getFileDiffs outputs --fixable issues and getErrors shows errors that are not ~~--fix~~ able?~

Any other inputs are welcome, since this is my first larger PR to an bigger project.

Hey Guys,

I've got a question for you. Since Symfony 3.3, there have been added new EventDispatcher features, that
dropped added value of SymplifyEventDispatcher for Symfony.

Only usable case remains Nette. There is similar package by @f3l1x : https://github.com/contributte/event-dispatcher

That does pretty much the same thing. Last few months I've realized I can invest to package that add more than just a few % of added value, instead of maintaining a 90% similar product.

1. So I would be happy to deprecate this package in favor of @f3l1x one. That means, it would be still available for years and current composer supported versions, just not developed.**

My question is - would you consider that a good way to continue or not? And why?

2. I asked @enumag on PM, and he would be ok, just missing ::class based event naming instead of string one.

$this->eventDispatcher(ApplicationRequestEvent::NAME); 
// alows to open event right away

instead of

$this->eventDispatcher(ApplicationEvents::ON_STARTUP);
// contributte, string only

For me, that would a detail, since on my own events I can use ::class regardless the package.

What do you think? About 1. and 2.

/cc @f3l1x @enumag @Lexinek @fprochazka

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

> ecs check --fix 'src'

Fatal error: Uncaught Error: Call to undefined function ECSPrefix20210928\React\Promise\resolve() in /var/www/html/sw6/vendor-bin/cs-fixer/vendor/symplify/easy-coding-standard/vendor/react/promise/src/Promise.php:203
Stack trace:
#0 /var/www/html/sw6/vendor-bin/cs-fixer/vendor/symplify/easy-coding-standard/vendor/react/socket/src/TcpConnector.php(73): ECSPrefix20210928\React\Promise\Promise::ECSPrefix20210928\React\Promise\{closure}(Object(ECSPrefix20210928\React\Socket\Connection))
#1 /var/www/html/sw6/vendor-bin/cs-fixer/vendor/symplify/easy-coding-standard/vendor/react/event-loop/src/StreamSelectLoop.php(209): ECSPrefix20210928\React\Socket\TcpConnector->ECSPrefix20210928\React\Socket\{closure}(Resource id #813)
#2 /var/www/html/sw6/vendor-bin/cs-fixer/vendor/symplify/easy-coding-standard/vendor/react/event-loop/src/StreamSelectLoop.php(175): ECSPrefix20210928\React\EventLoop\StreamSelectLoop->waitForStreamActivity(NULL)
#3 /var/www/html/sw6/vendor-bin/cs-fixer/vendor/symplify/easy-coding-standard/src/Console/Command/W in /var/www/html/sw6/vendor-bin/cs-fixer/vendor/symplify/easy-coding-standard/vendor/react/promise/src/Promise.php on line 203

Install symplify/easy-coding-standard-prefixed and run ecs -h:

PHP Fatal error:  Uncaught Error: Class "_PhpScoper3d66e802e797\Composer\InstalledVersions" not found in /home/runner/work/toolbox/toolbox/build/tools/.composer/vendor-bin/tools/vendor/symplify/easy-coding-standard-prefixed/vendor/jean85/pretty-package-versions/src/PrettyVersions.php:17
#0 /home/runner/work/toolbox/toolbox/build/tools/.composer/vendor-bin/tools/vendor/symplify/easy-coding-standard-prefixed/vendor/symplify/package-builder/src/Composer/PackageVersionProvider.php(34): _PhpScoper3d66e802e797\Jean85\PrettyVersions::getVersion()
1010
#1 /home/runner/work/toolbox/toolbox/build/tools/.composer/vendor-bin/tools/vendor/symplify/easy-coding-standard-prefixed/vendor/symplify/package-builder/src/Composer/PackageVersionProvider.php(19): Symplify\PackageBuilder\Composer\PackageVersionProvider->getVersion()
1011
#2 /home/runner/work/toolbox/toolbox/build/tools/.composer/vendor-bin/tools/vendor/symplify/easy-coding-standard-prefixed/src/Console/EasyCodingStandardConsoleApplication.php(33): Symplify\PackageBuilder\Composer\PackageVersionProvider->provide()
1012
#3 /tmp/easy_coding_standard_kernel/ContainerI5tERxi/getEasyCodingStandardConsoleApplicationService.php(20): Symplify\EasyCodingStandard\Console\EasyCodingStandardConsoleApplication->__construct()
1013
#4 /tmp/easy_coding_standard_kernel/ContainerI5tERxi/Symplify_EasyCodingStandard_HttpKernel_EasyCodingStandardKernelProd60146Container.php(204): ContainerI5tERxi\getEasyCodingStandardConsoleApplicationService::do()
1014
#5 /home/runner/work/toolbox/toolbox/build/tools/.composer/vendor-bin/tools/vendor/symplify/easy-coding-standard-prefixed/vendor/symfony/dependency-injection/Container.php(218): ContainerI5tERxi\Symplify_EasyCodingStandard_HttpKernel_EasyCodingStandardKernelProd60146Container->load()
1015
#6 /home/runner/work/toolbox/toolbox/build/tools/.composer/vendor-bin/tools/vendor/symplify/easy-coding-standard-prefixed/vendor/symfony/dependency-injection/Container.php(203): _PhpScoper3d66e802e797\Symfony\Component\DependencyInjection\Container->make()
1016
#7 /home/runner/work/toolbox/toolbox/build/tools/.composer/vendor-bin/tools/vendor/symplify/easy-coding-standard-prefixed/bin/ecs.php(37): _PhpScoper3d66e802e797\Symfony\Component\DependencyInjection\Container->get()
1017
#8 /home/runner/work/toolbox/toolbox/build/tools/.composer/vendor-bin/tools/vendor/symplify/easy-coding-standard-prefixed/bin/ecs(5): require('...')
1018
#9 {main}
1019
  thrown in /home/runner/work/toolbox/toolbox/build/tools/.composer/vendor-bin/tools/vendor/symplify/easy-coding-standard-prefixed/vendor/jean85/pretty-package-versions/src/PrettyVersions.php on line 17

Trying to upgrade ECS to latest again and I'm getting another really weird problem. When I run vendor/bin/ecs check I always get only a single error even though there are dozens cases of the same problem in other files. Doesn't matter if I add --clear-cache or not.

Hi 👋

As of today, csfix is broken in our project. When running vendor/bin/ecs check src --fix, I get:

PHP Fatal error:  Uncaught Symfony\Component\DependencyInjection\Exception\RuntimeException: Cannot autowire service "Symplify\TokenRunner\DocBlock\DescriptionAnalyzer": argument "$typeNodeAnalyzer" of method "__construct()" references class "Symplify\BetterPhpDocParser\PhpDocParser\TypeNodeAnalyzer" but no such service exists. in /foo/bar/vendor/symfony/dependency-injection/Compiler/DefinitionErrorExceptionPass.php:54
Stack trace:
#0 /foo/bar/vendor/symfony/dependency-injection/Compiler/AbstractRecursivePass.php(82): Symfony\Component\DependencyInjection\Compiler\DefinitionErrorExceptionPass->processValue(Object(Symfony\Component\DependencyInjection\Definition), true)
#1 /foo/bar/vendor/symfony/dependency-injection/Compiler/DefinitionErrorExceptionPass.php(32): Symfony\Component\DependencyInjection\Compiler\AbstractRecursivePass->processValue(Array, true)
#2 /foo/bar/vendor/symfony/dependency-injection/Compiler/AbstractRecursivePass.php(46): Symfony\Component\DependencyInjec in /foo/bar/vendor/symfony/dependency-injection/Compiler/DefinitionErrorExceptionPass.php on line 54

The project is using the latest Symfony 4.2.4, with symplify/easy-coding-standard version 5.4.13.

Is this a small bug in ECS, or have I messed something up?

<?php

namespace Ostrolucky\Stdinho;

/**
 * @package Ostrolucky\Stdinho
 */
class A
{
}

config:

services:
    PhpCsFixer\Fixer\Phpdoc\GeneralPhpdocAnnotationRemoveFixer:
        annotations: [package]
    Symplify\CodingStandard\Fixer\Commenting\RemoveEmptyDocBlockFixer:

output:

    ---------- begin diff ----------
--- Original
+++ New
@@ -3,8 +3,7 @@
 namespace Ostrolucky\Stdinho;
 
 /**
- * @package Ostrolucky\Stdinho
  */
 class A
 {
 }
\ No newline at end of file

    ----------- end diff -----------

expected output:

    ---------- begin diff ----------
--- Original
+++ New
@@ -3,8 +3,7 @@
 namespace Ostrolucky\Stdinho;
 
-/**
- * @package Ostrolucky\Stdinho
- */
 class A
 {
 }
\ No newline at end of file

    ----------- end diff -----------

There are actually 2 issues here: First is priority problem, second is that RemoveEmptyDocBlockFixer requires presence of method/variable

~Using ksort fixed PackageComposerJsonMergerTest.~

~But CombineStringsToArrayJsonMergerTest is still failing.~

As a reminder to myself, here're the failed tests:

There were 2 failures:

1) Symplify\MonorepoBuilder\Tests\Package\CombineStringsToArrayJsonMergerTest::testSharedNamespaces
Failed asserting that two arrays are identical.
--- Expected
+++ Actual
@@ @@
     'autoload' => Array &1 (
         'psr-4' => Array &2 (
             'ACME\Model\Core\' => Array &3 (
-                0 => 'packages/A'
-                1 => 'packages/B'
+                0 => 'packages/B'
+                1 => 'packages/A'
             )
             'ACME\Another\' => 'packages/A'
-            'ACME\YetAnother\' => Array &4 (
+            'ACME\YetAnother\' => 'packages/A'
+            'ACME\YetYetAnother\' => Array &4 (
                 0 => 'packages/A'
             )
-            'ACME\YetYetAnother\' => 'packages/A'
         )
     )
 )

Symplify/packages/MonorepoBuilder/tests/Package/CombineStringsToArrayJsonMergerTest.php:55

2) Symplify\MonorepoBuilder\Tests\Package\PackageComposerJsonMergerTest::test
Failed asserting that two arrays are identical.
--- Expected
+++ Actual
@@ @@
 Array &0 (
     'require' => Array &1 (
+        'symplify/symplify' => '^2.0'
         'rector/rector' => '^2.0'
         'phpunit/phpunit' => '^2.0'
-        'symplify/symplify' => '^2.0'
     )
     'autoload' => Array &2 (
         'psr-4' => Array &3 (
+            'Symplify\MonorepoBuilder\' => 'src'
             'Symplify\Statie\' => 'src'
-            'Symplify\MonorepoBuilder\' => 'src'
         )
     )
 )

Symplify/packages/MonorepoBuilder/tests/Package/PackageComposerJsonMergerTest.php:59

Steps to reproduce:

symfony new monolog-test
cd monolog-test/
composer require symplify/default-autowire
php bin/console server:start

Now add DefaultAutowireBundle to AppKernel.php.

In the browser you should see this error.

Unable to autowire argument index 1 ($excludedUrls) for the service "monolog.activation_strategy.not_found". If this is an object, give it a type-hint. Otherwise, specify this argument's value explicitly.

Related Changes

• dropped FinalTestCase, use SlamCsFixer\FinalInternalClassFixer instead
• added BlankLineAfterStrictTypesFixer

Todo

• [x] make php7 set run only php7, dissable nullable and void types on sniff

• [ ] update https://www.tomasvotruba.cz/blog/2017/08/21/5-useful-rules-from-symplify-coding-standard/

Following monorepo-builder's README leads to this result:

$ composer require symplify/monorepo-builder --dev

./composer.json has been created
Running composer update symplify/monorepo-builder
Loading composer repositories with package information
Updating dependencies
Lock file operations: 1 install, 0 updates, 0 removals
  - Locking symplify/monorepo-builder (11.1.24)
Writing lock file
Installing dependencies from lock file (including require-dev)
Package operations: 1 install, 0 updates, 0 removals
  - Installing symplify/monorepo-builder (11.1.24): Extracting archive
Generating autoload files
1 package you are using is looking for funding.
Use the `composer fund` command to find out more!
No security vulnerability advisories found
Using version ^11.1 for symplify/monorepo-builder

$ vendor/bin/monorepo-builder init

 [OK] Congrats! Your first monorepo is here.                                                                            
 ! [NOTE] Try the next step - merge "composer.json" files from packages to the root one:                                
 !         "vendor/bin/monorepo-builder merge"                                                                          

$ vendor/bin/monorepo-builder merge

 [ERROR] Class "Symplify\ComposerJsonManipulator\ValueObject\ComposerJsonSection" not found

I don't have the required experience to properly investigate, but my guess would be that this is a regression of #3474 caused by #4510.

Projects like Laravel who wants to use this rule will get immediate complaints as their code is of the following structure:

- app
- tests
- vendors

This PR avoids such errors while maintaining the intent.

I did not see where to apply tests, please point me in the right direction if necessary.

Thought some test cases for the comments would be great. I already tried to tackle some basic comment transfers but the array make it very complex. So not sure about how to process here. If somebody have idea it would be great to take it over.

In version 11.1.11 and hight it fails with error Call to undefined function ECSPrefix202210\trigger_deprecation().

It fails at vendor/symplify/easy-coding-standard/vendor/symfony/dependency-injection/ContainerBuilder.php:896.

This is a shorter example. I think the issue is using a constant as the key, or maybe it's using a class constant rather than a PHP constant. Likely this test can be merged with constant.yaml.

Addresses #4436