[psr_autoloading] Configuration must be an array and may not be empty.

[clxmstaab]

Bug report

updating from 2.18.2 to 2.18.3 we get the error when running php-cs-fixer fix

[psr_autoloading] Configuration must be an array and may not be empty.

this feels like a bug, because the docs mention this setting can be null or string

https://cs.symfony.com/doc/rules/basic/psr_autoloading.html

Code snippet that reproduces the problem

config

<?php

$finder = PhpCsFixer\Finder::create()
    ->in([
        __DIR__.'/app',
        __DIR__.'/config',
        __DIR__.'/lib',
        __DIR__.'/models',
        __DIR__.'/public',
        __DIR__.'/scripts',
    ])
;

return PhpCsFixer\Config::create()
    ->setUsingCache(true)
    ->setRules([
        '@Symfony' => true,
        '@Symfony:risky' => true,
        'array_syntax' => ['syntax' => 'short'],
        'fopen_flags' => false,
        'ordered_imports' => true,
        'protected_to_private' => false,
        'list_syntax' => ['syntax' => 'long'], // 'short' requires php 7.1+

        // custom rules for Motion
        // We need to disable psr_autoloading because it will change the classnames otherwise. PSR-0 autoloading is no solution!
        'psr_autoloading' => null,
    ])
    ->setRiskyAllowed(true)
    ->setFinder($finder)
;

[keradus]

this feels like a bug, because the docs mention this setting can be null or string
from docs:

dir¶
If provided, the directory where the project code is placed.

Allowed types: null, string

Default value: null

so, the config can be [ "dir" => "foo/bar" ] or [ "dir" => null ], this issue you are facing is sth else. thanks for raising

[nelsondevsquad]

This is also happening with the yoda_style property. Probably a general issue with array|null values.

[keradus]

'psr_autoloading' => null,

Question - why you are setting a null value? Configuration was never designed to use null as value for rule.
you can enable it (true), disable it (false) (eg when you inherited it enabled from ruleset), or configure it (with array).

null was never documented as valid value.
Unfortunately, so far, weakly-typed code treated null same as false, so your case was working.

I will be gentle here and replace hard validation with soft warning. To be hard validation again on 3.0 line

[clxmstaab]

Hey! thx for getting back to me.

Question - why you are setting a null value? Configuration was never designed to use null as value for rule.
you can enable it (true), disable it (false) (eg when you inherited it enabled from ruleset), or configure it (with array).

I am not the person who added this line of config. I am just the one reporting a BC break ;-).

I don't know what the intension of the author initially was or where he got inspiration from for this line of config.

null was never documented as valid value.
Unfortunately, so far, weakly-typed code treated null same as false, so your case was working.

I guess its a mix of 'it just worked' and 'while skimming the docs it seemed it would be a supported option'.
maybe the doc page can be improved somehow, it gets more obvious that "Allowed types: null, string" references the "dir"-argument and not the option itself.

I will be gentle here and replace hard validation with soft warning. To be hard validation again on 3.0 line

thx, that sounds like a great move from your side. really apreciate that.

[clxmstaab]

so, the config can be [ "dir" => "foo/bar" ] or [ "dir" => null ], this issue you are facing is sth else. thanks for raising

I am just testing this config settings.. using [ "dir" => null ] does not lead to the same result we had in the past, when just assigning null.

we want to effectivly disable the psr_autoloading because its renaming some classes which do not adhere to PSR (legacy code) and those should not be renamed.

[keradus]

to disable the rule, you need to psr_autoloading => false (and not psr_autoloading => null, which is invalid, nor psr_autoloading => [ dir => null ], which is enable the rule with custom config for it)

[Gounlaf]

@keradus

null was never documented as valid value.

According to the documentation, it is, at least for yoda_style:

• doc/rules/control_structure/yoda_style.rst:

  Write conditions in Yoda style (true), non-Yoda style (['equal' => false, 'identical' => false, 'less_and_greater' => false]) or ignore those conditions (null) based on configuration.

Like @clxmstaab I'm using a library that is doing this; that's why I reported #5538:

if (version_compare(\PhpCsFixer\Console\Application::VERSION, '2.6.0', '>=')) {
    $rules['yoda_style'] = null;
}

Edit: removed the reference for psr_autoloading