Closed InvisibleGit closed 1 year ago
Hey @InvisibleGit,
I am sorry that this change has broken your current workflow! Out of curiosity, does the CLI work if you don't run it from the same directory that contains the vendor
directory? For instance, if you are in another subdirectory of src
. According to the documentation on the installed_paths
option, relative paths are supposed to start with ./
and must be relative to the directory that PHPCS is executing from. In your case, if vendor/bin/phpcs
exists, you would want to set it to ./../wp-coding-standards/wpcs/
.
All of that to say, this seems like more of an issue with configuration than one with the extension.
Heyyah @ObliviousHarmony,
Here is the smallest project which shows the issue. I'm not sure if I'm doing something wrong with the config, but it'll be easier for you to understand the setup...
Opening a project extension complains with:
ERROR: the "./.phpcs.xml" coding standard is not installed. The installed coding standards are MySource, PEAR, PSR1, PSR2, PSR12, Squiz and Zend
yet if you go to src/
directory and run composer lint
you'll see that CLI works.
P.S. I didn't include vendors/
directory to keep the zip as small as possible, just run composer install
to get it...
Sorry, wrong button was clicked which closed the issue :(
Thanks @InvisibleGit,
I've taken a look at the reproduction you've supplied and confirmed my previous assessment. The installed_paths
in your supplied .phpcs.xml
file is invalid. Since you aren't using the relative path format described in the PHPCS documentation, the tool is resolving vendor/wp-coding-standards/wpcs
from whatever your current directory is. You can get your current configuration working by changing it to <config name="installed_paths" value="./../../wp-coding-standards/wpcs/" />
.
As an aside, generally speaking, I would advise against setting installed_paths
in this way. If you tried to use phpcs
installed using composer global require "squizlabs/php_codesniffer=*"
, your .phpcs.xml
file would not work at all. All of PHPCS' configuration options set using phpcs --config-set
will write to a file that is local to the install in question. If you ran vendor/bin/phpcs --config-set installed_paths ./../../wp-coding-standards/wpcs/
it would work without this option. You could then do the same for a global phpcs
install and both would work once you removed the option.
As is also suggested by the WordPress Coding Standards readme, you should prefer a Composer plugin that will sets the local installed_paths
for you based on the standards that are installed in your vendor
directory. Take a look at that section and you can get standard resolution working automatically without needing to worry about any of this.
Hope that helps!
Got it!
Thank you very much for your time and explanation and sorry for misunderstanding config issues.
I've changed the installed_paths and sure enough latest (v2.1.0) of extension started working. Ultimately I've chosen to use https://github.com/PHPCSStandards/composer-installer instead of explicitly naming phpcs installed_paths.
Hopefully this resolved issue might help someone else as well if they have similar issue.
Kindest regards...
Glad I could help @InvisibleGit. Good choice, that's what we use too :smile:
Description
With projects where phpcs and PHP files are in a subdirectory, for example "src/" of a workspace directory, vscode-php-codesniffer extension stops working since it can't find sniffs defined as relative paths in .phpcs.xml.
This is noted as a breaking change but there is no way to make it work in v2.x but forces using v1.7.0 where it did work.
Reproduction Steps
Create a project where .phpcs.xml in src/ subdirectory install Wordpress sniff with PHP composer Update .phpcs.xml to use Wordpress sniff as in:
<config name="installed_paths" value="vendor/wp-coding-standards/wpcs/" />
(note the relative path which issrc
/vendor/wp-coding-standards/wpcs/ relative to workspace)CLI works as usual, but vscode-php-codesniffer extension can't find Wordpress sniff though it's installed and properly configured in .phpcs.xml (it probably looks for vendor/ directory relative to workspace root, not src/ subdirectory)
Expected Behavior
Continue working as in v1.7.0, or at least provide an overriding config option for extension's current_directory
It seems all of this is related to noted breaking change:
the working directory given to PHPCS should always be the workspace root
which is too opinionated without an opt-out option.Thank you for the extension and your time...