Composer: allow for the 1.0.0 version of the Composer PHPCS plugin

[jrfnl]

The Composer PHPCS plugin has released its 1.0.0 version. 🎉

Important:
I've widened the version constraints for the plugin, instead of bumping it.

The reason for this is to prevent conflicts with end-user projects/other external PHPCS standards which may also require(-dev) the plugin, but may not (yet) have updated their constraints for the plugin. If the version would have been bumped instead of widened, those users would get an unsolvable conflict during the composer install run (unless they require-dev the plugin for the root project, but then, that's exactly what we don't want them to do as external standards managing the versions of the plugins should be more reliable).

Ref: https://github.com/PHPCSStandards/composer-installer/releases/tag/v1.0.0

[jrfnl]

The build failure is unrelated to this PR, see #307

[greg0ire]

unless they require-dev the plugin for the root project

I don't understand. Whether they require or require-dev the plugin in their composer.json should result in the very same conflict, shouldn't it?

[jrfnl]

unless they require-dev the plugin for the root project

I don't understand. Whether they require or require-dev the plugin in their composer.json should result in the very same conflict, shouldn't it?

It's not about require or require-dev. It's about version conflicts.

Say you would merge & release this fix today.
The Doctrine standard requires the slevomat/coding-standard package, which also requires the dealerdirect/phpcodesniffer-composer-installer package.
Now while a similar PR has been merged to the Slevomat standard, it hasn't been released yet, so if I would have set the version constraint to 1.0.0, it would block people from updating the Doctrine standard package until the Slevomat package would release the next version due to conflicts - this package requiring ^1.0.0, while Slevomat does not allow for ^1.0.0 yet -.

Along the same lines, if a user of the Doctrine standard would have a requirement for the dealerdirect/phpcodesniffer-composer-installer package in their composer.json and would have that set at ^0.7, they would again be blocked from updating the Doctrine standard if the version constraint would be set here to ^1.0.

Allowing for a wide range of versions of the plugin prevents these kind of issues and allows people time to either update their own version constraints or to remove the requirement for the plugin from their own package in favour of inheriting it from this package (which you could also consider, i.e. remove the requirement in favour of inheriting it from the Slevomat standard).

[greg0ire]

I understand that a user having ^0.7 for dealerdirect/phpcodesniffer-composer-installer would be blocked from upgrading if you hadn't left this wide version constraint range. Same for problem with Slevomat. What I don't understand is specifically this sentence:

unless they require-dev the plugin for the root project

But I guess it's not important.

[jrfnl]

Rebased without changes after the merge of #307 to get a passing build.

[derrabus]

I think, we can consider dropping older version of the plugin on the 12.x branch. Or even drop the dependency entirely: why should a coding standard bother how it is installed? But this is probably not the place for this discussion.

[derrabus]

Bold move, by the way! 😅

[jrfnl]

Or even drop the dependency entirely: why should a coding standard bother how it is installed? But this is probably not the place for this discussion.

As I don't follow this repo - here is my input for that discussion:
Dropping the dependency would be counter to the current trent where more and more external PHPCS standards are adding the plugin.

The plugin saves a user from potentially having to make error-prone manual changes to the PHPCS configuration, so is on the one hand a convenience a standard provides to end-users and on the other hand, saves maintainers having to deal with countless support questions from end-users about how to register the standard, which standards to register etc.

Why error-prone ? Because external standards have to be registered with PHPCS using --config-set and the value provided will overwrite any pre-existing value. Additionally users need to know which paths to register - for this standard, the paths to both the Slevomat standard as well as the Doctrine standard -.
To make things even more complicated, the exact path which needs to be register can be the path to the directory containing the ruleset.xml file or the path to the directory above it, depending on the PHPCS version.

Having the plugin in place automates this away as the plugin will do the discovery of available standards and registers them correctly.

[jrfnl]

Bold move, by the way! 😅

grin ah, well,, just staying in line with PHP_CodeSniffer itself, which currently still has PHP 5.4 as the minimum supported PHP version.
Keep in mind that the plugin still supports PHPCS 2.x, which has a minimum PHP requirement of PHP 5.1.2, so raising the minimum PHP version was a decision which really did need some discussion.

[derrabus]

Or even drop the dependency entirely: why should a coding standard bother how it is installed? But this is probably not the place for this discussion.

As I don't follow this repo - here is my input for that discussion: Dropping the dependency would be counter to the current trent where more and more external PHPCS standards are adding the plugin.

Okay, if that plugin is a de-facto standard, let's keep everything as it is. I trust you on this one. 🙂

[greg0ire]

Thanks @jrfnl !

[greg0ire]

Argh, this should have targeted 11.1.x, why do I always notice that kind of issue after merging 🤦 ?

[greg0ire]

💡 luckily there is nothing worth releasing to our users since 11.0.x, so I can just merge this up into 11.1.x, then release 11.1.0, it will do the trick.

[greg0ire]

Merge up PR: #308