Closed kkmuffme closed 6 months ago
@kkmuffme This issue is completely unclear to me. This plugin will use the PHP version used during the Composer install to run whatever commands it needs, but the end-result is a CodeSniffer.conf
file which is not specific to any particular PHP version and the same can be said about running PHPCS, so I don't understand what you are trying to report/what is the perceived problem.
1) set composer.json platform.php
to '8.3.0'
2) run composer install
(the default PHP executable must not be PHP 8.3 but e.g. 8.0)
3) run phpcbf with non-default PHP executable, e.g. /usr/bin/php83 /path/to/vendor/bin/phpcbf
=> Error:
Referenced sniff "WordPress" does not exist
*seems like this part got somehow removed in my OP, fixed now, this made it unclear
Cannot reproduce.
{
"name": "installes/216",
"require-dev": {
"squizlabs/php_codesniffer": "^3.8.0",
"wp-coding-standards/wpcs": "^3.0.1"
},
"config": {
"allow-plugins": {
"dealerdirect/phpcodesniffer-composer-installer": true
},
"platform": {
"php": "8.3.0"
}
}
}
$ composer install
PHP 8.0.30 (cli) (built: Sep 1 2023 14:15:38) ( ZTS Visual C++ 2019 x64 )
Copyright (c) The PHP Group
Zend Engine v4.0.30, Copyright (c) Zend Technologies
with Xdebug v3.2.2, Copyright (c) 2002-2023, by Derick Rethans
Composer version 2.6.6 2023-12-08 18:32:26
No composer.lock file present. Updating dependencies to latest instead of installing from lock file. See https://getcomposer.org/install for more information.
Loading composer repositories with package information
Updating dependencies
Lock file operations: 5 installs, 0 updates, 0 removals
- Locking dealerdirect/phpcodesniffer-composer-installer (v1.0.0)
- Locking phpcsstandards/phpcsextra (1.2.1)
- Locking phpcsstandards/phpcsutils (1.0.9)
- Locking squizlabs/php_codesniffer (3.8.1)
- Locking wp-coding-standards/wpcs (3.0.1)
Writing lock file
Installing dependencies from lock file (including require-dev)
Package operations: 5 installs, 0 updates, 0 removals
- Installing squizlabs/php_codesniffer (3.8.1): Extracting archive
- Installing dealerdirect/phpcodesniffer-composer-installer (v1.0.0): Extracting archive
- Installing phpcsstandards/phpcsutils (1.0.9): Extracting archive
- Installing phpcsstandards/phpcsextra (1.2.1): Extracting archive
- Installing wp-coding-standards/wpcs (3.0.1): Extracting archive
Generating autoload files
4 packages you are using are looking for funding.
Use the `composer fund` command to find out more!
PHP CodeSniffer Config installed_paths set to ../../phpcsstandards/phpcsextra,../../phpcsstandards/phpcsutils,../../wp-coding-standards/wpcs
$ php -v
PHP 8.3.0 (cli) (built: Nov 21 2023 17:48:31) (ZTS Visual C++ 2019 x64)
Copyright (c) The PHP Group
Zend Engine v4.3.0, Copyright (c) Zend Technologies
with Zend OPcache v8.3.0, Copyright (c), by Zend Technologies
with Xdebug v3.3.0alpha3, Copyright (c) 2002-2023, by Derick Rethans
$ "vendor/bin/phpcs" -i
The installed coding standards are MySource, PEAR, PSR1, PSR2, PSR12, Squiz, Zend, Modernize, NormalizedArrays, Universal, PHPCSUtils, WordPress, WordPress-Core, WordPress-Docs and WordPress-Extra
$ "vendor/bin/phpcs" -ps ./test.php --standard=WordPress
E 1 / 1 (100%)
FILE: test.php
-----------------------------------------------------------------------------
FOUND 1 ERROR AFFECTING 1 LINE
-----------------------------------------------------------------------------
1 | ERROR | Missing file doc comment (Squiz.Commenting.FileComment.Missing)
-----------------------------------------------------------------------------
Time: 574ms; Memory: 12MB
@kkmuffme Only thing I can think of at this moment is that your custom ruleset contains an <config...
setting overruling the installed paths or that something in your Composer scripts
is screwing things up.
I have some config directives in the ruleset:
<config name="minimum_wp_version" value="6.2"/>
<config name="testVersion" value="7.4-"/>
<config name="php_version" value="70400"/>
And also some CLI sets:
--runtime-set php_version 80000
For whatever reason this issue only occurred for phpcbf but not for phpcs making this even weirder.
Ah just saw your reproduction - this isn't my case though: in both your cases your "php" executable was the default one (despite being different versions)
The issue only happens when EXPLICITLY running it with a different PHP executable
in both your cases your "php" executable was the default one (despite being different versions)
No, I explicitly run with specific PHP versions, just do so under the hood. Shouldn't make a difference anyhow (and it doesn't).
$ C:\wamp\bin\php\php8.3.0\php.exe "vendor/bin/phpcs" -ps ./test.php --standard=WordPress --basepath=.
E 1 / 1 (100%)
FILE: test.php
-----------------------------------------------------------------------------
FOUND 1 ERROR AFFECTING 1 LINE
-----------------------------------------------------------------------------
1 | ERROR | Missing file doc comment (Squiz.Commenting.FileComment.Missing)
-----------------------------------------------------------------------------
Time: 623ms; Memory: 12MB
Seriously, please do some debugging yourself before reporting an issue and report it with a proper reproduction case. I've seen so many issues by you already and only 1 in 20 is valid.
I can still reproduce this consistently after upgrading phpcs via composer update
I have to explicitly run /usr/bin/php83 -d xdebug.mode=off /usr/bin/composer install
again to fix it.
Not a big deal though
@kkmuffme There might be something in your dependencies which is incompatible with PHP 8.0 (used during composer install
) which is causing a fatal error when the autoload file is requested on PHP 8.0 (which is needed to run any plugins).
Also see: https://github.com/PHPCSStandards/composer-installer/issues/79
Having said that, if that's the case, than:
platform.php
setting is not intended to allow you to use a low PHP version with a high platform setting. It is intended for allowing to run Composer on a higher version and prevent locking in dependencies not compatible with your minimum PHP version.1) I can reproduce it with the exact steps outlined above. Since the workaround is easy enough, I don't want to waste your and my time.
2) That's wrong, see the example from composer's docs :-) (lower PHP version with higher platform setting)
- I can reproduce it with the exact steps outlined above. Since the workaround is easy enough, I don't want to waste your and my time.
No you can't. There must be something else in your composer.json
which is causing the problem. And without that extra information it's a guessing game. (which, yes, has wasted my time)
2. That's wrong, see the example from composer's docs :-) (lower PHP version with higher platform setting)
See my previous answer. You can use it like that, but if anything in your dependencies will have installed something which includes syntax incompatible with the runtime PHP version for Composer, the autoload.php
file will throw a fatal and will block all plugins from working.
In other words, know your tools.
2) my runtime PHP version matches the platform.php I set as outlined in the OP.
Anyway, wish you a great day!
Problem/Motivation
The loaded rulesets seems to be PHP-executing version specific, while composer itself is not. My composer.json has
platform.php '8.3.0'
set. My default PHP is 8.0I install/update normally via
composer install
and see everything is correct:Then I run phpcbf with php 8.3 like: (my-ruleset.xml contains WordPress ruleset)
/usr/bin/php83 /path/to/vendor/bin/phpcbf --standard=/path/to/my-ruleset.xml /other/path/file.php
Expected behaviour
no error
Actual behavior
Error:
Fix
/usr/bin/php83 -d xdebug.mode=off /usr/bin/composer install
I get the same output as above
but then it works correctly.
Proposed changes
The config should be loaded independently of the actually executing PHP script. This is especially relevant in CI, where 1 PHP version might install packages for various executable PHP versions using
platform.php
.Environment
Tested against
main
branch?main
branch.