Interface 'PHP_CodeSniffer_Sniff' not found

[orion40]

On a centos7 machine, as root, with phpcs 3.3.0 and PHP 5.4.16, be it by downloading the latest release or pulling the source code, trying to use PHPCompatibility result in an error, which I will describe below.
I set the proper path, so that phpcs can use PHPCompatibility;
phpcs --config-set installed_paths /root/PHPCompatibility/PHPCompatibility/

Then, in the directory where there is the code to parse, I run:
phpcs -vsp --runtime-set testVersion 5.4 --standard=PHPCompatibility .

Which result with this error:
Registering sniffs in the PHPCompatibility standard... PHP Fatal error: Interface 'PHP_CodeSniffer_Sniff' not found in /root/PHPCompatibility/PHPCompatibility/Sniff.php on line 24

[jrfnl]

@orion40 This is a hard to debug issue as I cannot reproduce this behaviour.

It basically indicates that PHPCS has not loaded the PHPCSAliases.php file which it needs for PHPCS 3.x compatibility, while it should have.

The only reasons I can think of for that to happen would be:

• A PHPCSAliases.php file in the directory above the directory containing the test code. This could confuse PHPCS into loading the wrong file.
• The PHPCS version being used not actually being the 3.3.0 version which could happen if you have various versions installed on your system and and the directory for an older version is in your system $PATH. Try phpcs --version to see which PHPCS version is actually being used.

Also, you may want to try using phpcs --config-set installed_paths /root/PHPCompatibility/ instead.

[orion40]

Thanks for your quick reply. The output of phpcs --versionis:
PHP_CodeSniffer version 3.3.0 (stable) by Squiz (http://www.squiz.net)
I installed it via PEAR. (pear install PHP_CodeSniffer).
I've changed the path, now the root directory of PHPCompatibility is /root/PHPCompatibility/, which is also pointed to with --config-set installed_paths.
The same issue is present.

[jrfnl]

@orion40 I honestly don't know where to start debugging this, but would you mind testing some things for me ?

To begin with, could you try installing PHPCS and PHPCompatibility as project based dependencies via Composer ?
If the run works fine in that case, then we'd know that it is something specific to the installation via PEAR.

[orion40]

I have tried to use PHPCS by directly downloading the .phar, and there is still the same issue. I am going to try with composer.

[orion40]

Using composer (but on a different machine, a Debian Stretch), this time I get a completely different bug:
./vendor/bin/phpcs --standard=PHPCompatibility src/www/index.php PHP Fatal error: Uncaught Error: Call to undefined function simplexml_load_string() in /home/whoami/programming/taf/codendi_src/centos75/vendor/squizlabs/php_codesniffer/CodeSniffer.php:697 Stack trace: #0 /home/whoami/programming/taf/codendi_src/centos75/vendor/squizlabs/php_codesniffer/CodeSniffer.php(551): PHP_CodeSniffer->processRuleset('/home/whoami/pr...') #1 /home/whoami/programming/taf/codendi_src/centos75/vendor/squizlabs/php_codesniffer/CodeSniffer/CLI.php(830): PHP_CodeSniffer->initStandard(Array, Array) #2 /home/whoami/programming/taf/codendi_src/centos75/vendor/squizlabs/php_codesniffer/CodeSniffer/CLI.php(95): PHP_CodeSniffer_CLI->process() #3 /home/whoami/programming/taf/codendi_src/centos75/vendor/squizlabs/php_codesniffer/scripts/phpcs(25): PHP_CodeSniffer_CLI->runphpcs() #4 {main} thrown in /home/whoami/programming/taf/codendi_src/centos75/vendor/squizlabs/php_codesniffer/CodeSniffer.php on line 697

[jrfnl]

@orion40 That sounds like a completely different issue. Looks like lib_XML isn't enabled for the PHP version you are using on that machine and that's a requirement for PHPCS.

[kick-the-bucket]

Shouldn't it have failed on `composer install`, if the required extension isn't loaded?

[jrfnl]

@kick-the-bucket Good question, but not something which is within our purview. That should maybe be reported to the Composer repo ?

PHPCS does have the correct requirement in their composer.json as far as I can see:
https://github.com/squizlabs/PHP_CodeSniffer/blob/a2c94db37c042f95e9cb91bffabe7605cea64d8e/composer.json#L31

[jrchamp]

I believe I had the same problem as the original Centos box on a RHEL box. I had used pear to install phpcs. After I used pear to uninstall phpcs, I was able to use a local copy of phpcs with PHPCompatibility.

[cdayjr]

I'm running into the same issue on a CentOS 7 VM with PHP 5.4.16. At the moment I'm just installing it and trying to use it via composer, here's my composer.json file if that helps:

{
  "require-dev": {
    "squizlabs/php_codesniffer": "^3.3",
    "phpcompatibility/php-compatibility": "^8.2",
    "dealerdirect/phpcodesniffer-composer-installer": "^0.4.4",
    "roave/security-advisories": "dev-master",
    "phpmd/phpmd": "^2.6",
    "phpunit/phpunit": "4.8"
  },
  "require": {
    "php": "~5.4.16",
    "ircmaxell/password-compat": "^1.0"
  }
}

I gave PEAR a shot as @jrchamp suggested, but it didn't seem to help.

Interestingly, I tried adding the following lines near the top of the Sniff.php file:

  require_once dirname(__DIR__).'/PHPCSAliases.php';
  class_alias('PHP_CodeSniffer\Sniffs\Sniff', '\PHP_CodeSniffer_Sniff');

and I get this error:

PHP Warning:  Cannot redeclare class \PHP_CodeSniffer_Sniff in /vendor/phpcompatibility/php-compatibility/PHPCompatibility/Sniff.php on line 14
PHP Fatal error:  Interface 'PHP_CodeSniffer_Sniff' not found in /vendor/phpcompatibility/php-compatibility/PHPCompatibility/Sniff.php on line 27

So I don't believe it's an issue with loading the PHPCSAliases.php file; seems like the class_alias runs fine. I tried out class_exists and interface_exists and despite the "Cannot redeclare class" error, both return false.

Can anyone think of anything else to test and try and figure out what's happening here?

[andresmrg]

Did anyone find a solution?

[ljmf00]

Hi @andresmrg ,

I had the same issue, and as I understood, for cross-version compatibility, you should have something like class_alias( 'PHP_CodeSniffer\Sniffs\Sniff', '\PHP_CodeSniffer_Sniff' ); .

As @jrfnl said, you should be sure you load PHPCSAliases.php

At least, this works for me.

Thanks,
Luis

[jrfnl]

@ljmf00 Glad to hear you found a working solution for you.

The weird thing is that the PHPCSAliases.php file should be loaded automatically when it's needed (PHPCS 3.x).

The only time that file wouldn't be loaded automatically is if someone would try to include just a sniff or category from PHPCompatibility in their custom ruleset and not the standard.

[MassiCav]

Looking for a solution for this issue, occurring when 'phpcs' is configured with one single rule like:
<rule ref="PHPCompatibility.Variables.RemovedPredefinedGlobalVariables"/>

[jrfnl]

@MassiCav As I state just above your question:

The only time that file wouldn't be loaded automatically is if someone would try to include just a sniff or category from PHPCompatibility in their custom ruleset and not the standard.

So, if you include just one sniff from PHPCompatibility, you will need to add the below directive to your phpcs.xml.dist file:

<autoload>/path/to/PHPCompatibility/PHPCSAliases.php</autoload>

Note: as of the upcoming PHPCompatibility 10.0.0 this should no longer be needed when using PHPCS 3.x.