Normalizing of version constraints not suitable for all use-cases - can it be made disable/confgurable in some way ?

[sbuerk]

Steps required to reproduce the problem

1. composer require "php":"^7.4 || ^8.0 || ^8.1 || ^8.2 || ^8.3"
2. Execute composer normalize

Expected Result

• "php": "^7.4 || ^8.0 || ^8.1 || ^8.2 || ^8.3"

Actual Result

• "php": "^7.4 || ^8.0"

Remarks

I know that there are different opionons out there about how to deal with dependecy version constraints, and therefore I'd say a option to disable the dependency version constraint normalization at whole would be nice.

For me this means, the normalizer is not usable because of this - but I would pretty much use all
the other normalization this tools offers - specially as a pipeline check.

Can we made this a config / command option in some way ?

[fredden]

^8.0 already allows for / includes 8.1.2, so specifying ^8.1 is redundant. This tool is removing the redundancy.

As an example, compare https://semver.madewithlove.com/?package=composer%2Fcomposer&constraint=%5E2.5 with https://semver.madewithlove.com/?package=composer%2Fcomposer&constraint=%5E2.5+%7C%7C+%5E2.6

It looks like you intended to say "php":"~7.4.0 || ~8.0.0 || ~8.1.0 || ~8.2.0 || ~8.3.0". (Note the use of the tilde operator, not the caret operator.) https://getcomposer.org/doc/articles/versions.md#next-significant-release-operators

Note that by saying "php": "^7.4 || ^8.0", you're claiming support for PHP version 8.6, which does not exist at time of writing. I don't think that PHP follows semantic versioning, so using the caret operator doesn't make sense here.

[fredden]

Normalizing of version constraints not suitable for all use-cases

The example you have provided is where this tool removes a completely redundant set of constraints. Is this the only use-case that you don't like, or is there another example you can provide?

[sbuerk]

As mentioned, different opinions. Ack, technical it's redunant and there is no point against it. However, from a human readable point, expresession them in that way can be taken as "these are official supported minor php versions branches, newer once may work work or not. Which allows using higher php version to test it until it is added.

Using the stricter variant

~7.4.0 || ~8.0.0 || ~8.1.0 || ~8.2.0 || ~8.3.0

means that only these can be used and forbids newer php version per default. And if PHP 8.4 is released at some point requireing projects/packages needs to wait until it is added or using nasty platform-ignore-req hacks which opens other can of worms. It's matter of reading and understanding, not the pure technical aspect what it means and acts like.

Don't get me wrong - it was simply a question and I know a lot of people not using composer-normalize exactly out of this reason / behaviour.

I'm not asking for a default change in behaviour - only for a configurable opt-in. If that's not wanted it's fully okay. I don't want to fight about it. If a option is not reasonable to disable/change that behaviour I will simply not use composer normalizer as it is not suitable for me. (and maybe others). Doing the work to fork the dependency chain and maintain it is not worth for me.

[localheinz]

@sbuerk

Allowing to configure ergebnis/composer-normalize beyond the existing configuration options is something I would like to avoid - it's unnecessary complexity.

Having said that, I agree with @fredden's comment #1287 (comment).

Example

Running

composer require composer/semver

and creating a file test.php with the following content

<?php

declare(strict_types=1);

use Composer\Semver;

require_once __DIR__ . '/vendor/autoload.php';

$parser = new Semver\VersionParser();

$one = $parser->parseConstraints('^7.4 || ^8.0 || ^8.1 || ^8.2 || ^8.3');
$two = $parser->parseConstraints('^7.4 || ^8.0');

var_dump(
    $one->matches($two),
    $two->matches($one),
);

and running

php test.php

yields

bool(true)
bool(true)

The example above confirms what @fredden said in #1287 (comment).

Documenting PHP version support

If you want to document your PHP version support and prevent installation of a package on unsupported versions of PHP you could use the ~ operator, as suggested by @fredden.

For reference, see

• Fix: Use ~ operator to limit compatibility with PHP versions php-package-template#1086
• [RFC]: Allow better constraint handling for PHP laminas/laminas-diactoros#117 (comment)