WordPress/WordPress-Coding-Standards

PHPCSutils_ Refernce_Error

zakitekhqs opened this issue · 7 comments

Issue:
I have moved to Linux(Ubuntu Debian). Installed the 'phpcs' using composer and it worked but when installed 'wpcs' using composer did not work. So I cloned it from Git.

Now I have set paths and standards are installed but when I use phpcs --standard=WordPress 'path to file', it gives below error.

ERROR: Referenced sniff "Universal.NamingConventions.NoReservedKeywordParameterNames" does not exist.

Actions:

  • I have installed PHPCSutils and PHPCSExtra but still see the issue.
  • Reinstalled composer , phpcs but same error/
jrfnl commented

As of WordPressCS 3.0.0, Composer is the only supported manner of installation for that reason. Please install using Composer as per the installation instructions in the README.

alanef commented

Installed with Composer

ERROR: Referenced sniff "PHPCSUtils" does not exist

{ "config": { "platform": { "php": "7.4.33" }, "allow-plugins": { "dealerdirect/phpcodesniffer-composer-installer": true } }, "require-dev": { "wp-coding-standards/wpcs": "^3.0" } }

but installing 2.30 the same way works

Are you using phpcs from the global installation or from your vendor folder?

I installed the above code to my computer, and when running vendor/bin/phpcs -i I can see the following:

The installed coding standards are MySource, PEAR, PSR1, PSR2, PSR12, Squiz, Zend, Modernize, NormalizedArrays, Universal, PHPCSUtils, WordPress, WordPress-Core, WordPress-Docs and WordPress-Extra
alanef commented

I'm running from vendor

Like you I'm seeing PHPCSUtils, when I do a -i yet it fails

reverting versions in the exact same env works

how can I help debug further?

alanef commented

OK

Resolved

To upgrade from 2.3.0 to 3.0.0 you need to extend your installed_paths

to include phpcsstandards/phpcsextra and phpcsutils

e.g.

<config name="installed_paths" value="./../../wp-coding-standards/wpcs,./../../phpcsstandards/phpcsutils,./../../phpcsstandards/phpcsextra"/>

jrfnl commented

@alanef No, you should removed that <config.. completely as is spelled out in the Upgrade Guide as it overwrites what the Composer plugin sets (which will always be correct, while what you are doing needs manual maintenance and keeping up with dev changes in this repo).

alanef commented

Thanks for pointing out the upgrade docs