erickskrauch / php-cs-fixer-custom-fixers Goto Github PK

Hi @erickskrauch

The current logic for calculating the length of a type does not consider php8 union types. Could you please let know if you plan to include similar logic?

#5

At first, thanks for publishing this extension.

With

'ErickSkrauch/align_multiline_parameters' => ['variables' => false, 'defaults' => false],

and

    public function bar(
        string ...$zxc,
    ) {
    } 

I get

    public function bar(
        string ... $zxc,
    ) {
    }

as a result, which is not expected.

I can solve this issue by reusing logic from ErickSkrauch/align_multiline_parameters. It shouldn't be too difficult :clueless:

If you add a dev keyword, Composer magically knows your package should be --dev requirement.

See https://php.watch/articles/composer-prompt-require-dev-dev-packages

Here is a bug:

function test(
    string $string = "string",
    int |
    (
        JsonSerializable
        &
        Stringable
    )|
    null $int = 0
) {}
}

This is a weird but the correct way to write a type. Right now the AlignMultilineParametersFixer will calculate the length of the type with all those tabulation spaces and put the names of the parameters really far away to the left.

The PHP-CS-Fixer's TypesSpacesFixer doesn't fix such multiline type declarations and I didn't find any other fixer suited for this task, so it seems that this code was left on the user's side.

It seems that I can calculate the length of each line and take the longest line as the type length:

function test(
    string               $string = "string",
    int |
    (
        JsonSerializable
        &
        Stringable
    )|
    null                 $int = 0
) {}
}

But I'm not sure about this solution at this moment. So I'll leave this issue open until somebody also occurs this in a real code and gives me some feedback about expected behavior.

Hi @erickskrauch,

thanks for a great project, exactly what I'm looking for.

I think I might have encountered an issue, though.

I'd like to use ErickSkrauch/align_multiline_parameters, but it seems to be irritated when type hints are nullable, as in ?string or ?RequestStack.

This is the change it proposed, for a function declaration that already adheres to the align_multiline_parameters rules:

     public function __construct(
         EntityManagerInterface         $entityManager,
         LoggerInterface                $logger,
-        ?RequestStack                  $requestStack,
+        ?RequestStack                              $requestStack,
         WebDeveloperToolsHelperService $webDeveloperToolsHelperService

When using 'ErickSkrauch/align_multiline_parameters' => ['variables' => true] we get an unexpected style fixing for classes with promoted properties without a type:

Before:

/**
 * @template T
 */
class Diff
{
    /**
     * @param T $was
     * @param T $expected
     */
    public function __construct(
        public $was,
        public $expected,
    ) {
    }
}

After:

/**
 * @template T
 */
class Diff
{
    /**
     * @param T $was
     * @param T $expected
     */
    public function __construct(
        public
        $was,
        public
        $expected,
    ) {
    }
}

Expected (No change):

/**
 * @template T
 */
class Diff
{
    /**
     * @param T $was
     * @param T $expected
     */
    public function __construct(
        public $was,
        public $expected,
    ) {
    }
}

During the review, I encountered that the developer added the implementation of new methods to the end of the class, while in the interface these methods were described above. I remarked and asked to fix it for code consistency, but I realized that this is a stylistic remark, which means that it either shouldn't be made at all or should be implemented as an automatic tool.

Example

Before fix:

interface Basic {

    public function firstMethod();

    public function secondMethod();

    public function thirdMethod();

}

final class BasicImplementation implements Basic {

    public function firstMethod() {
        // Code
    }

    public function thirdMethod() { // Out of order!
        // Code
    }

    public function secondMethod() {
        // Code
    }

}

After fix:

final class BasicImplementation implements Basic {

    public function firstMethod() {
        // Code
    }

    public function secondMethod() {
        // Code
    }

    public function thirdMethod() { // Now on its place
        // Code
    }

}

Notes:

• The implementation should work correctly with php-doc and attributes.
• The fixer must run before ordered_class_elements.
• The fixer should work for interfaces, extended interfaces, abstract classes, and non-final classes.