installed_paths depend on PHP executable? #216

kkmuffme · 2024-01-16T20:37:50Z

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.0

I install/update normally via composer install and see everything is correct:

PHP CodeSniffer Config installed_paths set to ....,../../wp-coding-standards/wpcs

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:

Referenced sniff "WordPress" does not exist

Fix

/usr/bin/php83 -d xdebug.mode=off /usr/bin/composer install

I get the same output as above

PHP CodeSniffer Config installed_paths set to ....,../../wp-coding-standards/wpcs

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

Question	Answer
OS	Linux
PHP version	8.3
Composer PHPCS plugin version	1.0.0
Install type	Composer global

Tested against `main` branch?

I have verified the issue still exists in the main branch.

The text was updated successfully, but these errors were encountered:

jrfnl · 2024-01-16T21:05:02Z

@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.

kkmuffme · 2024-01-16T21:11:18Z

set composer.json platform.php to '8.3.0'
run composer install (the default PHP executable must not be PHP 8.3 but e.g. 8.0)
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

jrfnl · 2024-01-16T21:30:06Z

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

jrfnl · 2024-01-16T21:32:10Z

@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.

kkmuffme · 2024-01-16T21:37:37Z

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.

kkmuffme · 2024-01-16T21:39:08Z

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

jrfnl · 2024-01-16T21:46:42Z

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.

kkmuffme · 2024-01-16T21:50:49Z

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

jrfnl · 2024-01-16T22:05:59Z

@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: #79

Having said that, if that's the case, than:

You still never provided a valid reproduction case. Purely based on the info provided, this issue cannot be reproduced.
It is a not a problem with this plugin, but a problem with how you run Composer.
The 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.

kkmuffme · 2024-01-16T22:11:30Z

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.
That's wrong, see the example from composer's docs :-) (lower PHP version with higher platform setting)

jrfnl · 2024-01-16T22:38:38Z

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.

kkmuffme · 2024-01-16T22:41:29Z

my runtime PHP version matches the platform.php I set as outlined in the OP.

Anyway, wish you a great day!

jrfnl added the triage label Jan 16, 2024

jrfnl added the can't reproduce / won't fix label Jan 16, 2024

kkmuffme closed this as completed Jan 16, 2024

kkmuffme closed this as not planned Won't fix, can't repro, duplicate, stale Jan 16, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

installed_paths depend on PHP executable? #216

installed_paths depend on PHP executable? #216

kkmuffme commented Jan 16, 2024 •

edited

Loading

jrfnl commented Jan 16, 2024

kkmuffme commented Jan 16, 2024 •

edited

Loading

jrfnl commented Jan 16, 2024

jrfnl commented Jan 16, 2024

kkmuffme commented Jan 16, 2024

kkmuffme commented Jan 16, 2024

jrfnl commented Jan 16, 2024 •

edited

Loading

kkmuffme commented Jan 16, 2024

jrfnl commented Jan 16, 2024 •

edited

Loading

kkmuffme commented Jan 16, 2024

jrfnl commented Jan 16, 2024

kkmuffme commented Jan 16, 2024

installed_paths depend on PHP executable? #216

installed_paths depend on PHP executable? #216

Comments

kkmuffme commented Jan 16, 2024 • edited Loading

Problem/Motivation

Expected behaviour

Actual behavior

Fix

Proposed changes

Environment

Tested against main branch?

jrfnl commented Jan 16, 2024

kkmuffme commented Jan 16, 2024 • edited Loading

jrfnl commented Jan 16, 2024

jrfnl commented Jan 16, 2024

kkmuffme commented Jan 16, 2024

kkmuffme commented Jan 16, 2024

jrfnl commented Jan 16, 2024 • edited Loading

kkmuffme commented Jan 16, 2024

jrfnl commented Jan 16, 2024 • edited Loading

kkmuffme commented Jan 16, 2024

jrfnl commented Jan 16, 2024

kkmuffme commented Jan 16, 2024

kkmuffme commented Jan 16, 2024 •

edited

Loading

Tested against `main` branch?

kkmuffme commented Jan 16, 2024 •

edited

Loading

jrfnl commented Jan 16, 2024 •

edited

Loading

jrfnl commented Jan 16, 2024 •

edited

Loading