Adding custom Fixers to PHP CS Fixer

[superbiche]

Hi again,

Hopefully this time it's not just me missing something: when creating the .php-cs-fixer.dist.php file in my project, it's picked correctly by Duster.

But I don't understand how to add custom rules: when adding Fixers following https://github.com/PHP-CS-Fixer/PHP-CS-Fixer/blob/master/doc/custom_rules.rst, I get a Class [class of custom fixer] not found.
This seems to be related to the packaging of Duster using Box, I guess it cannot use the global autoloader?

For now I forked the project, added the custom Fixers, and built it (btw a "How To Build" could help others) but I don't want to maintain a fork for just a couple custom Fixers.

Is there a way to "wire" local / project dependencies to the Duster binary ?

Thanks in advance

[driftingly]

Hi @superbiche, thank you for the feedback on these projects 🙌
I think you're right about the core issue here. I'll take a look to see if anyone offered suggestions to the Pint package that we might be able to use here. I might have some time this Friday to go through the issues you're running into.

There is https://github.com/tighten/duster/blob/2.x/RELEASE.md, which I rely on when releasing. I may need to link this in the readme.

[superbiche]

Hi @driftingly you're welcome, thanks for the work on this project, it's really helpful.

Oh OK, I missed the RELEASE.md, yes maybe linking to it in the README would help.

I don't know Box / PHARs enough but maybe there's a way to configure some external autoloader or composer.json that could be loaded during runtime.

Hopefully there's an easy way to solve this!

[superbiche]

I found this comment quite relevant to this issue: #86 (comment)

Namespacing the project so the source code can be included like a regular Composer dependency - using source install - might be the shortest path to making custom fixers addition a breeze.
imo easier than trying to include external dependencies from a PHAR archive, but again, I don't know much about PHARs)

[driftingly]

Hi @superbiche,

I'm not sure changing the namespace will work because I still rely on classes under Pint, which will keep the App namespace. I made a quick test branch you can try at https://github.com/tighten/duster/tree/drift/change-namespace with the changes required. Can you pull this into a project to test whether this updated namespace works?

[superbiche]

Thanks @driftingly, I'll have to wait until I work back on a Laravel 10 project later this week in order to test this.
Will let you know as soon as I can give it a shot.

[Joel-Jensen]

Hi @driftingly, update on the test.

Installed the branch "tightenco/duster": "dev-drift/change-namespace"but sadly ran into the same problem as the author.

Class "Inly\DusterPresets\CustomLivewireOrderFixer" not found

<?php

use App\Fixer\ClassNotation\CustomControllerOrderFixer;
use App\Fixer\ClassNotation\CustomOrderedClassElementsFixer;
use App\Fixer\ClassNotation\CustomPhpUnitOrderFixer;
use App\Support\PhpCsFixer;
use Inly\DusterPresets\CustomLivewireOrderFixer;
use PhpCsFixer\Config;

return (new Config())
    ->setFinder(PhpCsFixer::getFinder())
    ->setUsingCache(false)
    ->registerCustomFixers([
        new CustomControllerOrderFixer(),
        new CustomLivewireOrderFixer(),
        new CustomOrderedClassElementsFixer(),
        new CustomPhpUnitOrderFixer(),
    ])
    ->setRules([
        'Tighten/custom_controller_order' => true,
        'Inly/custom_livewire_order' => true,
        'Tighten/custom_ordered_class_elements' => [
            'order' => [
                'use_trait',
                'case',
                'property_public_static',
                'property_protected_static',
                'property_private_static',
                'constant_public',
                'constant_protected',
                'constant_private',
                'property_public',
                'property_protected',
                'property_private',
                'construct',
                'method:__invoke',
                'method_public_static',
                'method_protected_static',
                'method_private_static',
                'method_public',
                'method_protected',
                'method_private',
                'magic',
            ],
        ],
        'Tighten/custom_phpunit_order' => true,
    ]);

[driftingly]

Thanks for testing @Joel-Jensen
Looks like I'll have to come at it from a different angle.

[superbiche]

Hi @driftingly sorry for not testing your branch, I had no time to work on this again before now.

The namespace change doesn't respond to our need, but it doesn't break anything and make the IDE happy. Imo this should be something to merge in a future major release.

I've made some tests today, the problem is that even if a dependency is installed in the root project, Duster's autoloader doesn't have access to it.
I tried to override the autoloader, but it's not trivial and it's not working correctly. But I think this could be an option.

I also tried creating a Composer installer plugin to install the dependency in the duster directory, but with no luck (and it's a really dirty hack anyway).

Otherwise, all I can think of are 3 other approaches:

• Make it possible to load Duster's code directly in, say, an Artisan command. But the use statements clash depending on the Laravel version
• Make a Duster "Builder", that can be customized before compiling it. This would make it hard to install using Composer though, it would be downloaded instead.
• Find a way to customize Duster composer.json "in place" once it's installed.

Any thoughts about all this?

In the meantime, using a fork is not optimal, but it's okay, so thanks again for the great work on this project