Discovered while debugging the build failure of #97
The PHPCS --config-show command shows all config settings set, not just the installed_paths and since PHPCS 3.1.0, it also includes a line to indicate which configuration file is being used to help with debugging configuration issues.
Example:
Using config file: I:/path/to/project/vendor/squizlabs/php_codesniffer/CodeSniffer.conf
default_standard: Squiz
installed_paths: ../../phpcompatibility/php-compatibility
show_progress: 1
In PHPCS 2.0 - 3.0.1, if any other configuration options were set, aside from installed_paths, the result of the loadInstalledPaths() command would be broken.
In PHPCS 3.1.0+, the result would always be broken, no matter what.
In effect this means that the installed_paths would (nearly) always be set as if the config was previously non-existent as the cleanInstalledPaths() method would empty out the array as the values contained therein would be invalid anyway.
It would be lovely if it were possible to add unit tests, but as we're talking about a private method setting a private property...
So, for now, to proof the bug and validate the fix, I've set up a "fake" unit test to demonstrate what the previous behaviour was and what the behaviour will be with this fix in place: https://3v4l.org/brrNT
I suspect that this may fix some mystery issues previously reported.
Proposed Changes
Discovered while debugging the build failure of #97
The PHPCS
--config-showcommand shows all config settings set, not just theinstalled_pathsand since PHPCS 3.1.0, it also includes a line to indicate which configuration file is being used to help with debugging configuration issues.Example:
In PHPCS 2.0 - 3.0.1, if any other configuration options were set, aside from
installed_paths, the result of theloadInstalledPaths()command would be broken.In PHPCS 3.1.0+, the result would always be broken, no matter what.
In effect this means that the
installed_pathswould (nearly) always be set as if the config was previously non-existent as thecleanInstalledPaths()method would empty out the array as the values contained therein would be invalid anyway.It would be lovely if it were possible to add unit tests, but as we're talking about a
privatemethod setting aprivateproperty...So, for now, to proof the bug and validate the fix, I've set up a "fake" unit test to demonstrate what the previous behaviour was and what the behaviour will be with this fix in place: https://3v4l.org/brrNT
I suspect that this may fix some mystery issues previously reported.