Closed rilwis closed 10 months ago
@rilwis I've tried, but cannot reproduce your issue.
This is what I did to try and reproduce the issue:
phpcs-3880
composer.json
in that directory.phpcs.xml.dist
test.php
file with some code - <?php echo $var;
- which should trigger an error based on your ruleset.elightup
repos from the composer.json
as I don't have access to them.composer install
.vendor/bin/phpcs -i
and got the following output:
The installed coding standards are MySource, PEAR, PSR1, PSR2, PSR12, Squiz, Zend, PHPCompatibility, PHPCompatibilityParagonieRandomCompat, PHPCompatibilityParagonieSodiumCompat, PHPCompatibilityWP, Modernize, NormalizedArrays, Universal, PHPCSUtils, WordPress, WordPress-Core, WordPress-Docs and WordPress-Extra
vendor/bin/phpcs - v
and got the following output:
# "vendor/bin/phpcs" -v
Registering sniffs in the eLightUp WordPress Coding Standards standard... DONE (298 sniffs registered)
Creating file list... DONE (1 files in queue)
Changing into directory path/to/phpcs-3880
Processing test.php [PHP => 7 tokens in 3 lines]... DONE in 360ms (1 errors, 0 warnings)
In other words, without more information to allow someone to reproduce your issue, there is nothing anyone can do.
It might help to know what versions of various packages are installed and on which OS, but you removed the "Versions" table from the bug report template.
P.S.: [WordPressCS 3.0.0 has been released](https://make.wordpress.org/core/2023/08/21/wordpresscs-3-0-0-is-now-available/), so I suggest you update your `require-dev` to use `^3.0` for the `wp-coding-standards/wpcs` package.
More info in the [changelog](https://github.com/WordPress/WordPress-Coding-Standards/releases/tag/3.0.0) and [upgrade guide](https://github.com/WordPress/WordPress-Coding-Standards/wiki/Upgrade-Guide-to-WordPressCS-3.0.0-for-ruleset-maintainers).
@jrfnl
That's strange.
When I replicate your test with the same steps, I see it works as you described.
However, when I check with my code, I can't find anything wrong. I recorded a screencast so you can see what I'm doing:
https://mega.nz/file/X6w0BZQR#8z7GAtfTPlxpWTcQDWIEKrFIXKafcyGMaaE28mvkaPg
I also updated the issue with "Versions" section for more details.
@rilwis I can see that you've listed the PHP_CodeSniffer version as 3.8.0
, but that version does not exist currently: https://github.com/squizlabs/PHP_CodeSniffer/tags. Please can you confirm what version you're using, and perhaps how you've installed PHP_CodeSniffer? I don't see this listed in the composer.json
file supplied, so I have to assume that it's installed somewhere else on your system. If you install it directly into this project (with composer require --dev squizlabs/php_codesniffer
), does this work as expected?
I've watched the video now. I wonder if this is a duplicate of https://github.com/composer/composer/issues/11555. @rilwis please can you confirm what version of Composer you are using? Please can you also compare the output of vendor/bin/phpcs -i
with vendor/squizlabs/php_codesniffer/bin/phpcs -i
?
Edit: upon further reflection, this can't be a duplicate of that bug, because PHP_CodeSniffer doesn't check $_SERVER['SCRIPT_NAME']
.
Edit2: please can you supply the last few lines of vendor/bin/phpcs
? I'm expecting this to end with include __DIR__ . '/..'.'/squizlabs/php_codesniffer/bin/phpcs';
When I replicate your test with the same steps, I see it works as you described.
The steps there include removing all the "elightup" packages. Might they be causing this issue? @rilwis please can you confirm if the bug exists with/without these packages?
@rilwis Just watched the video and in the video you mention something "cleaning the vendor/bin" directory (and that also shows at the end of the composer install
). I'm 99% sure that will be your problem and that is something we can't help you with as PHPCS does not supply that tooling, nor have I ever heard of it before.
[1:08] I can also see in the video that before the cleaning, PHPCS is installed correctly as the Composer PHPCS installer plugin does its work and gives output - the "installed _paths set to ..." bit in the composer install
output before the cleaning and as that plugin uses PHPCS natively under the hood, PHPCS is installed correctly at that point.
So my suggestion would be to get rid of whatever tooling that is "cleaning" (breaking) the vendor/bin
directory as that is probably your problem.
I also noticed in the video that after modifying composer.json
in your text editor, you only run composer install
and don't actually re-install any files. There's a warning from Composer that its content-hash no longer matches. The "cleaned" files are probably still there; I'd recommend deleting all of vendor/
when making changes such as that, before running composer install
to get Composer to put the files in place.
Sorry for the late reply. I've just back from a holiday.
Regarding the questions, I've recorded a new video to show you a whole process:
https://mega.nz/file/amIDVBYY#LTAmlDnEaiw9M89RvcMwE-_cuk1rQmGpp4h1jMKna1k
What I did:
extra
rules (which were used to remove redundant files in vendor
folder). So everything now looks like a normal Composer install.composer install
. The vendor
folder is now fresh and has proper files../vendor/bin/phpcs -v
and nothing appears.Note that I have phpcs
installed on my machine globally, so when I run phpcs -v
, it outputs things correctly. Only the local version of phpcs
, which is ./vendor/bin/phpcs
, doesn't output anything.
Thanks for the update @rilwis. I notice in this new video that you are still not installing the packages that you think you are. This is because you do not modify the composer.lock
file when making changes to the composer.json
file in your editor. There's a warning from Composer when you run composer install
saying this too.
Please can you try again with this script. None of this requires you to leave the terminal / use your editor.
# set up
set -x
cd $(mktemp -d)
git clone git@github.com:elightup/slim-seo-link-manager.git .
# confirm bug is still present
composer install
vendor/bin/phpcs -i
# remove packages not available to the public
composer config --unset repo.1
composer config --unset repo.0
composer config --unset extra.dev-files
composer remove elightup/plugin-updater elightup/plugin-search
# test if bug still persists
vendor/bin/phpcs -i
vendor/bin/phpcs -v
# some diagnostics
head -n 1 vendor/bin/phpcs
type php
php --version
composer --version
composer show
composer global show
composer global depends composer-plugin-api
@fredden
Thanks for the scripts. Here are the screenshots:
I guess it's working after removing packages. But don't know why.
@rilwis This sounds like it just confirms that this is not a PHPCS problem, but a problem with one or both of those two (private
) packages. I suggest you report your issue there.
After testing again with some commands, I found that when I run:
composer remove elightup/plugin-search
Then the command ./vendor/bin/phpcs -i
works again.
However, when I require elightup/plugin-search
, then it failed.
Digging a little deeper, in the repo elightup/plugin-search
, the autoload rule loads a file bootstrap.php
, which contains some code for WordPress specifically. When running vendor/bin/phpcs -i
, this file is also loaded. And because this is not a WordPress installation, the bootstrap.php
file causes an error and makes the script fails.
I think it can be mentioned somehow in the docs, that any autoload files must run properly in the CLI environment, in order to not break phpcs
.
I think this issue can be closed now.
Thank you very much for your help!
I think it can be mentioned somehow in the docs, that any autoload files must run properly in the CLI environment, in order to not break phpcs.
That is not just an issue for PHPCS, but for literally every tool out there. If you have a files
autoload directive, it is a given that that file should always run without side-effects.
I had the same problem here. It was inside my own code being autoloaded with a files autoloader.
"autoload": {
"files": [
"lib/functions.php"
]
},
I at the top of functions.php
I had:
if ( ! defined( 'ABSPATH' ) ) {
exit;
}
which I changed to
if ( ! defined( 'ABSPATH' ) ) {
return;
}
and things began to work again.
@BrianHenryIE Same fix here. Thanks a lot! Great job, made my day!
Describe the bug
I installed PHPCS and some other rules for a local package, which is a WordPress plugin. And when I run
phpcs
, it doesn't output anything.Here is my
composer.json
file:Custom ruleset
Here is my
phpcs.xml
file:To reproduce
After installing dependencies, when I run the following commands nothing is outputted in the console:
I also run them with variations like setting the
--standard="phpcs.xml"
or set the folder to./src/
, etc. - still no luck.Versions (please complete the following information)
Additional context
I tried to add some
die
to thevendor/squizlabs/php_codesniffer
folder to debug, and found that the code stops atautoload.php
file, on this line:https://github.com/squizlabs/PHP_CodeSniffer/blob/master/autoload.php#L77
It seems to load Composer's autoload, and then stops.
I don't know how to debug further.
Please take a look.
Please confirm:
master
branch of PHP_CodeSniffer.