composer / semver Goto Github PK

Hey there, i have a question about the constraint logic syntax supported by this package:

Why is || supported for logical OR, but && is not supported for logical AND?

I mean, it's documented to work that way, so it's not a bug or anything, but i'm curious. Having been exposed to the || syntax independently, i just assumed that && would also work.

Thanks!

After update composer to version 1.10.11 I'm getting error from update command at any project

[UnexpectedValueException]
Could not parse version constraint dev-load-varnish-only-when-used as ^2.0@dev: Invalid version string "^2.0@dev"

Launch composer with -vvv option show

app@host:~$ composer update --dry-run -vvv
... skip
Downloading http://repo.packagist.org/p/symfony/polyfill-php70%24688cb065da992de6111ec75cde05ada182f93b8e58dbef5bb21674c882aa334e.json
Writing /home/app/.composer/cache/repo/https---repo.packagist.org/provider-symfony$polyfill-php70.json into cache

[RuntimeException]
Could not load package ezsystems/ezplatform in http://repo.packagist.org: [UnexpectedValueException] Could not parse version constraint dev-load-varnish-only-when-used as ^2.0@dev: Invalid version str
ing "^2.0@dev"

https---repo.packagist.org/provider-symfony$polyfill-php70.json contains string "ezsystems/ezplatform-http-cache":"dev-load-varnish-only-when-used as ^2.0@dev" that break last semver commit 07ed0f4#diff-d31fb7758d82628c36d95136856a69ca

Returns Invalid version string "1.0.0.0.1".

The case is that custom pear packages may have this type of versions. The problem is in composer when tries to install this type of pear package that it fails because normalize function from this scripts fails and in consequence the package is skipped while adding to pear repository.

This is valid version and is comparable with function version_compare (http://php.net/manual/en/function.version-compare.php)

This type of versions are used by people.. For example if there is version of package 1.0.0, the package of translation of this package may be 1.0.0.1, later 1.0.0.2, and so on..

If this is not a bug, than there is bug in composer main package to use this semver also for pear repositories..

If a composer.json contains an invalid php version constraint:

{
    ...
    "config": {
        "platform": {
            "php": "^7.0"
        }
    },
    ...
}

It's not alerted by the diagnose command, but when i give another command, like composer update, it throwns an UnexpectedValueException with the message: Invalid version string "^7.0"

Hi, i need to check if two versions constraints 5.7.* are equal, and not want to do with comparator ===.

But my surprirse is, when i check this line Comparator::equalTo($this->composer['require'][$dependency], $version), the result is false, but the two strings are 5.7.*.

Somebody can help me?

Hello there 👋

If I try to test the version 1.0.*-stable with Semver::satisfies the following error shows up:

[UnexpectedValueException] Could not parse version constraint 1.0.*-stable: Invalid version string "1.0.*-stable"

Every other constraint seems to work. Am I doing something wrong or is this a bug?

Best regards

I have found another subtle bug in the VersionParser.php.

The following constraint used to be invalid with the message the alias source must be an exact version, if it is a branch name you should prefix it with dev-

^1.0 as 0.9.1

I added that to the failingConstraints() data provider in VersionParserTest.php and ran the tests for 1.5.0, The test still passes (the constraint is rejected properly)

If you add that constraint to 1.7.1, the test fails, because it is not rejected.

Sorry that our flood of bad data is surfacing these subtle bugs. It only affects one project on packages.drupal.org, so we've just blitzed the metadata for those old versions as a workaround.

Opening the issue just in case it hits packagist / other repos harder.

I noticed that composer/semver treats tilde differently compared to npm/semver:

It is probably too late to change it now. But it is worth noting down perhaps, somewhere.

see composer/spdx-licenses#1

While playing around with the VersionParser I noticed that it accepts the following version

1.0.0<1.0.5-dev or also 1.0.0-dev<1.0.5-dev

It fails on the version without the dev stability suffix but with -dev it works because of https://github.com/composer/semver/blob/master/src/VersionParser.php#L162

Subsequent code (for example generating Intervals) can't work correctly with the Constraint VersionParser produces but no error occurs.
On side of composer it just does not find a version for the package this kind of version is used on. This is the same in composer 1.10.X with semver 1.X
So for composer I consider this problem very minor.

My expectation is that it throws an error like it does without the dev stability.

The name EmptyConstraint is quite confusing. This is a match-all constraint, so the set of matched versions is not empty at all. And its string representation is not empty either (as that's *).

Of course, we will need to keep a deprecated EmptyConstraint child class for BC.

I think it was also an issue in #86 so pinging @jderusse here as well.

I've encountered this issue while working on composer/composer#8850 and it's a show stopper.
I'm trying to find out if other package versions need to be loaded but that doesn't work reliably.
The problem is the matches() method. Checkout the following example:

<?php

require_once 'vendor/autoload.php';

use Composer\Semver\VersionParser;

$versionParser = new VersionParser();
$exactConstraint = $versionParser->parseConstraints('1.0.0');
$rangeConstraint = $versionParser->parseConstraints('1.*');

var_dump($exactConstraint->matches($rangeConstraint)); // true
var_dump($rangeConstraint->matches($exactConstraint)); // true

So if a package required a dependency in exactly 1.0.0 we would never load the other 1.* versions because it would always match :(

The question is, what does matches() really mean and how can we solve this issue?

As written on semver.org:

• A pre-release version MAY be denoted by appending a hyphen and a series of dot separated identifiers immediately following the patch version. Identifiers MUST comprise only ASCII alphanumerics and hyphen [0-9A-Za-z-]. Identifiers MUST NOT be empty. Numeric identifiers MUST NOT include leading zeroes. Pre-release versions have a lower precedence than the associated normal version. A pre-release version indicates that the version is unstable and might not satisfy the intended compatibility requirements as denoted by its associated normal version. Examples: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92.
• Build metadata MAY be denoted by appending a plus sign and a series of dot separated identifiers immediately following the patch or pre-release version. Identifiers MUST comprise only ASCII alphanumerics and hyphen [0-9A-Za-z-]. Identifiers MUST NOT be empty. Build metadata SHOULD be ignored when determining version precedence. Thus two versions that differ only in the build metadata, have the same precedence. Examples: 1.0.0-alpha+001, 1.0.0+20130313144700, 1.0.0-beta+exp.sha.5114f85.

Do we want to follow these as close to the letter as possible?

Hi,

I am a little bit confused about the version constraint. In different other packages (https://docs.npmjs.com/misc/semver) and tools (https://github.com/jubianchi/semver-check) the previous constraints work in special ways.

Example from the known behavoir:

~1.2.3 => >=1.2.3 <1.3.0
~1.2 => >=1.2.0 <1.3.0
~0.2.3 => >=0.2.3 <0.3.0
~0.2 => >=0.2.0 <0.3.0

^1.2.3 => >=1.2.3 <2.0.0
^1.2 => >=1.2.0 <2.0.0
^0.2.3 => >=0.2.3 <0.3.0
^0.2 => >=0.2.0 <0.3.0

Example with composer:

~1.2.3 => >=1.2.3 <1.3.0
~1.2 => >=1.2.0 <2.0.0 *
~0.2.3 => >=0.2.3 <0.3.0
~0.2 => >=0.2.0 <1.0.0 *

^1.2.3 => >=1.2.3 <2.0.0
^1.2 => >=1.2.0 <2.0.0
^0.2.3 => >=0.2.3 <0.3.0
^0.2 => >=0.2.0 <0.3.0

* difference

To check it, I was adding the following test cases to the satisfiedByProvider in the SemverTest.php

/**
 * @return array
 */
public function satisfiedByProvider()
{
    return array(
        array(
            '~1.0',
            array('1.0', '1.2', '1.9999.9999', '2.0', '2.1', '0.9999.9999'),
            array('1.0', '1.2', '1.9999.9999'),
        ),
        array(
            '>1.0 <3.0 || >=4.0',
            array('1.0', '1.1', '2.9999.9999', '3.0', '3.1', '3.9999.9999', '4.0', '4.1'),
            array('1.1', '2.9999.9999', '4.0', '4.1'),
        ),
        array(
            '^0.2.0',
            array('0.1.1', '0.1.9999', '0.2.0', '0.2.1', '0.3.0'),
            array('0.2.0', '0.2.1'),
        ),
        array(
            '~1.2.3',
            array('1.2.2', '1.2.3', '1.2.4', '1.3.0', '1.4.0', '2.0.0'),
            array('1.2.3', '1.2.4'),
        ),
        array(
            '~1.2',
            array('1.2.2', '1.2.3', '1.2.4', '1.3.0', '1.4.0', '2.0.0'),
            array('1.2.2', '1.2.3', '1.2.4', '1.3.0', '1.4.0'),
        ),
        array(
            '~0.2.3',
            array('0.2.2', '0.2.3', '0.2.4', '0.3.0', '0.4.0', '1.0.0'),
            array('0.2.3', '0.2.4'),
        ),
        array(
            '~0.2',
            array('0.2.2', '0.2.3', '0.2.4', '0.3.0', '0.4.0', '1.0.0'),
            array('0.2.2', '0.2.3', '0.2.4', '0.3.0', '0.4.0'),
        ),
        array(
            '^1.2.3',
            array('1.2.2', '1.2.3', '1.2.4', '1.3.0', '1.4.0', '2.0.0'),
            array('1.2.3', '1.2.4', '1.3.0', '1.4.0'),
        ),
        array(
            '^1.2',
            array('1.2.2', '1.2.3', '1.2.4', '1.3.0', '1.4.0', '2.0.0'),
            array('1.2.2', '1.2.3', '1.2.4', '1.3.0', '1.4.0'),
        ),
        array(
            '^0.2.3',
            array('0.2.2', '0.2.3', '0.2.4', '0.3.0', '0.4.0', '1.0.0'),
            array('0.2.3', '0.2.4'),
        ),
        array(
            '^0.2',
            array('0.2.2', '0.2.3', '0.2.4', '0.3.0', '0.4.0', '1.0.0'),
            array('0.2.2', '0.2.3', '0.2.4'),
        ),
    );
}

At the end I dont really know, if its a bug, but its a difference, which confuses me. Is it a conscious decision? If it is that, why?

Many thanks in advance for your help.

with the 1.10.13 release of composer we see errors regarding invalid version strings, which did work perfectly before this release.

maybe we relied on undocumented behaviour, maybe there is some kind of regression going on.. lets discuss ;-).

we use composer constraints like

"my/package" : "dev-my-branch-name as dev-a-release-branch-name",

which worked before but now errors with

"complex/rocket" : "dev-code-refactory-for-better-readability as dev-CLX6_2020R01",

->

composer update
                                                                                                                                
  [UnexpectedValueException]                                                                                                                        
  Invalid version string "CLX6_2020R01-dev" in "dev-code-refactory-for-better-readability as CLX6_2020R01-dev", the alias must be an exact version 

ENV:

composer diagnose

Checking platform settings: OK
Checking git settings: OK
Checking http connectivity to packagist: OK
Checking https connectivity to packagist: OK
Checking github.com oauth access: OK
Checking disk free space: OK
Checking pubkeys:
Tags Public Key Fingerprint: 57815BA2 7E54DC31 7ECC7CC5 573090D0  87719BA6 8F3BB723 4E5D42D0 84A14642
Dev Public Key Fingerprint: 4AC45767 E5EC2265 2F0C1167 CBBB8A2B  0C708369 153E328C AD90147D AFE50952
OK
Checking composer version: OK
Composer version: 1.10.13
PHP version: 7.4.5
PHP binary path: C:\tools\php74\php.exe
OpenSSL version: OpenSSL 1.1.1e  17 Mar 2020

Composer unable to install google-closure-compiler package with the composer-asset-plugin due to a version number parsing issue. I'm trying to install the npm packages of Angular2, but it seems that the VersionParser class thinks the version number of the package (20150920.0.0) is invalid. Looks to me the check is too strict in that it only allows the major version to be up to five digits, but just changing the check makes a date-based version string fail a phpunit test, so I wasn't quite sure how this should be handled.

Here's a minimal compos er.json to reproduce the problem:

{
    "require": {
        "npm-asset/google-closure-compiler": "20150920.0.0"
    }
}

composer -vvv update output:

composer -vvv update
Reading ./composer.json
Loading config file /Users/ere/.composer/config.json
Loading config file /Users/ere/.composer/auth.json
Loading config file ./composer.json
Executing command (/Users/ere/src/composertest): git describe --exact-match --tags
Executing command (/Users/ere/src/composertest): git branch --no-color --no-abbrev -v
Executing command (/Users/ere/src/composertest): hg branch
Executing command (/Users/ere/src/composertest): svn info --xml
Reading ./composer.json
Loading config file /Users/ere/.composer/config.json
Loading config file /Users/ere/.composer/auth.json
Loading config file ./composer.json
Executing command (/Users/ere/src/composertest): git describe --exact-match --tags
Executing command (/Users/ere/src/composertest): git branch --no-color --no-abbrev -v
Executing command (/Users/ere/src/composertest): hg branch
Executing command (/Users/ere/src/composertest): svn info --xml



  [UnexpectedValueException]
  Could not parse version constraint 20150920.0.0: Invalid version string "20150920.0.0"



Exception trace:
 () at phar:///usr/local/bin/composer/vendor/composer/semver/src/VersionParser.php:467
 Composer\Semver\VersionParser->parseConstraint() at phar:///usr/local/bin/composer/vendor/composer/semver/src/VersionParser.php:248
 Composer\Semver\VersionParser->parseConstraints() at phar:///usr/local/bin/composer/src/Composer/Package/Loader/ArrayLoader.php:234
 Composer\Package\Loader\ArrayLoader->parseLinks() at phar:///usr/local/bin/composer/src/Composer/Package/Loader/ArrayLoader.php:124
 Composer\Package\Loader\ArrayLoader->load() at phar:///usr/local/bin/composer/src/Composer/Package/Loader/RootPackageLoader.php:86
 Composer\Package\Loader\RootPackageLoader->load() at phar:///usr/local/bin/composer/src/Composer/Factory.php:284
 Composer\Factory->createComposer() at phar:///usr/local/bin/composer/src/Composer/Factory.php:504
 Composer\Factory::create() at phar:///usr/local/bin/composer/src/Composer/Console/Application.php:245
 Composer\Console\Application->getComposer() at phar:///usr/local/bin/composer/src/Composer/Command/Command.php:53
 Composer\Command\Command->getComposer() at phar:///usr/local/bin/composer/src/Composer/Command/UpdateCommand.php:88
 Composer\Command\UpdateCommand->execute() at phar:///usr/local/bin/composer/vendor/symfony/console/Command/Command.php:259
 Symfony\Component\Console\Command\Command->run() at phar:///usr/local/bin/composer/vendor/symfony/console/Application.php:841
 Symfony\Component\Console\Application->doRunCommand() at phar:///usr/local/bin/composer/vendor/symfony/console/Application.php:192
 Symfony\Component\Console\Application->doRun() at phar:///usr/local/bin/composer/src/Composer/Console/Application.php:167
 Composer\Console\Application->doRun() at phar:///usr/local/bin/composer/vendor/symfony/console/Application.php:123
 Symfony\Component\Console\Application->run() at phar:///usr/local/bin/composer/src/Composer/Console/Application.php:98
 Composer\Console\Application->run() at phar:///usr/local/bin/composer/bin/composer:43
 require() at /usr/local/bin/composer:25


update [--prefer-source] [--prefer-dist] [--dry-run] [--dev] [--no-dev] [--lock] [--no-plugins] [--no-custom-installers] [--no-autoloader] [--no-scripts] [--no-progress] [--with-dependencies] [-v|vv|vvv|--verbose] [-o|--optimize-autoloader] [-a|--classmap-authoritative] [--ignore-platform-reqs] [--prefer-stable] [--prefer-lowest] [--] [<packages>]...

Could I use this library to parse a composer.json file?

The string representation includes additional [ ] around the constraint, which means that parsing the string representation as a constraint fails

My rough understanding of Composer internals related to SAT solving is that it registers multiple pools of providers and based on requirements and a voodoo dance, determines a set of "best matching" providers that meet satisfiability requirements of the requiring package.

My question is whether or not some of this logic might make its way down to this package. I am just curious because I'm currently having to maintain a minimal implementation of this for another project and am so excited to see semver pulled out like this! Anywho, fully understand if that would be considered "out of scope" for this package, but was just curious if there were plans for that or if the project would be open to even splitting that out as another separate component.

Sorry for rambling 😄

Thanks for all you folks do!

I released 0.1.0-beta.3 of my project yesterday. Unfortunately it contained a critical bug, so I fixed and proceeded to release 0.1.0-beta.3.1. From semver.org:

1. A pre-release version MAY be denoted by appending a hyphen and a series of dot separated identifiers immediately following the patch version. [...] Examples: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92.

Packagist wasn't picking up the tag for some reason. I investigated and traced the problem back to here (while I don't have hard proof that this is indeed the problem, this is what I suspect that it is).

I found that composer/composer's VcsRepository will skip a tag if it doesn't validate.

Tag validation uses the VersionParser from composer/semver.

So I checked out VersionParser, and it seems that the regex that matches the pre-release modifier only allows one numeric pre-release identifier. i.e. it will match 0.1.0-beta.3, but not 0.1.0-beta.3.1.

Is there a good reason for this? Would it be possible to fix?

Hello!
I used Semver::satisfies($v, $version) for checking and got this:

joomla/input: ~1.2|~2.0 satisfied by 1.2.1
joomla/filter: ~1.0 satisfied by 1.3.3
joomla/string: ~1.3|~2.0 satisfied by 1.4.1
joomla/registry: ^1.4.5|~2.0 satisfied by 1.6.0
joomla/compat: ~1.0 satisfied by 1.2.0
joomla/utilities: ^1.4.1|~2.0 satisfied by 1.5.0
symfony/polyfill-php55: ~1.0 satisfied by v1.7.0
ircmaxell/password-compat: ~1.0 satisfied by v1.0.4
psr/log: ~1.0 satisfied by 1.0.2

I'm newbie in this theme but I guess this list contains errors. It's strange, seems ~ behaves like ^. May be I must use some additional shecking or some additional parameters?

Could this be handled by making pre an alias of RC? It seems to be the intention wherever I see it used.

Hi, we have a Gentoo package for semver and would like our users to be able to run the test suite when they install it to catch unexpected incompatibilities. But we install the release tarballs (they use less space, can be gpg signed, don't require git as a build dependency, etc), and the releases don't have the tests in them.

Would you consider adding them? Thanks!

Needs documentation. Considering this library is a wee bit larger than composer/spdx-licenses, I reckon it deserves proper documentation. E.g. not just some basic usage description in the README. Any suggestions / feedback?

Composer install is giving me a warning about this package because it depends on an abanadoned library
https://packagist.org/packages/phpunit/phpunit-mock-objects

Is there plans to replace it?

Intervals class got really big and consists of functions of very different tasks. Out of blackbox view they also have not much to do with the idea of the Intervals class. Similarity is just using intervals internally.

I like to do the following changes:

• Move compactConstraint to new Optimize class
• Move isSubsetOf and haveIntersections to Comparator
• Set generateIntervals to public as it is used in haveInspections or solve that differently.

If you agree to this it should be done in a new major release. Otherwise we end up in duplicated code or cross references to deprecate the old functions.

For a script I want to gather lots of constraints but also want to remove redundancy.
So far I did not figure out how composer/semver can be used to solve this so maybe it is a new feature.

Examples:

• < 8.0.2 || < 8.0.2 should be sanitized to < 8.0.2
• < 8.0.2 || < 8.0.1 should be sanitized to < 8.0.2

And other types of conjunctions or even more complex scenarios like

~ 7.0 || < 7.5.2 || 6.9.1 || > 7.1 || dev-master which could be the same as 6.9.1 || ~7.0 || dev-master

If I have the following list of available versions:

$availableVersions = [
    '2.0.0',
    'dev-master',
    '1.x-dev',
    '1.0.0',
    '1.0.0-RC2',
    '1.0.0-RC1',
    '1.0.0-RC',
    '1.0.0-beta2',
    '1.0.0-beta1',
    '1.0.0-beta',
    '1.0.0-alpha2',
    '1.0.0-alpha1',
    '1.0.0-alpha',
]

Then:

$constraint = '^1.0';

$versions = [];
foreach ($availableVersions as $availableVersion) {
    if (Semver::satisfies($availableVersion, constraint)) {
        $versions[] = $availableVersion;
    }
}

I would expect the result to be:

$versions = [
    '1.0.0',
]

Likewise, I would expect for $version = ^1.0@beta to give me:

$versions = [
    '1.0.0',
    '1.0.0-RC2',
    '1.0.0-RC1',
    '1.0.0-RC',
    '1.0.0-beta2',
    '1.0.0-beta1',
    '1.0.0-beta',
]

Yet in both cases I'm getting:

```php
$versions = [
    'dev-master',
    '1.x-dev',
    '1.0.0',
    '1.0.0-RC2',
    '1.0.0-RC1',
    '1.0.0-RC',
    '1.0.0-beta2',
    '1.0.0-beta1',
    '1.0.0-beta',
    '1.0.0-alpha2',
    '1.0.0-alpha1',
    '1.0.0-alpha',
]

Looking at the code, I can see that for the caret at least, the default stability is dev whilst I would expect stable instead. Is there any way to change that or I am missing something?

Not sure if feasible at all nor how easy or efficient it would be, but I think it'd be worth investigating if we can turn ^1.0|^2.0 into >=1.0 && <3.0-dev when parsing constraints. Basically merge contiguous ORs into one bigger OR. It'd make things more efficient when comparing but obviously it shouldn't take 10x longer to generate or it'll offset the gains.

Not sure if this is a bug but the following will fail:

        $versionRequire = new Constraint('==', '1');
        $versionProvide = new Constraint('==', '1.0');

        $this->assertTrue($versionRequire->matches($versionProvide));

this happens due to php's version_compare function evaluating 1 < 1.0 < 1.0.0

Some inspiration can be found at https://github.com/npm/node-semver#functions - I think it'd be nice to have a more comprehensive toolkit than version_compare in PHP. We have all the underlying code just needs to be made a bit more usable as a wrapper class or something.

Hi,

The last tag (1.5.0) seems to be signed, thanks. Unfortunately, the format looks weird, and cannot be verified (git tag -v 1.5.0 fails).

Regards

I am try to upgrade 2.0.0 to 2.1.7.

Installation Guide : https://www.mgt-commerce.com/tutorial/how-to-upgrade-magento2-with-composer

As regard installation guide 6th step getting stuck.

Fatal error: Class 'Composer\Semver\VersionParser' not found in C:\wamp\www\gta\ vendor\composer\composer\src\Composer\Package\Version\VersionParser.php on line 17

My VersionParser.php file : https://justpaste.it/5x351

How can i solve this error.

\Composer\Semver\Constraint\ConstraintInterface::matches returns false-positive result if '||' is used in constraint.

Code:

 $versionParser = new \Composer\Semver\VersionParser();
 $constraint1 = $versionParser->parseConstraints('>=2.3.1 <2.3.4');
 $constraint2 = $versionParser->parseConstraints('2.3.0 || >=2.3.4 <2.4.2');
 var_dump($constraint1->matches($constraint2));

Expected result (version 1.7.2):
false

Actual result (version 3.2.4):
true

UPD
Looks like it's some edge case. If we use '10.0.0 || >=2.3.4 <2.4.2' in example above then the result is correct.
But in case of '1.0.0 || >=2.3.4 <2.4.2' the result is wrong. If the value < 2.3.1 then we have an issue.

Follow up on #107

I still have some projects running into problems with Composer 1.10.12 / Semver 3.1.0. For the time being, I've solved it by downgrading Composer to 1.10.10, so no rush.

I can't seem to figure out what the problem version constraint is though.

The problem seems to be with phpcsstandards/phpcsdevtools.

phpcsstandards/phpcsdevtools composer.json

{
  "name" : "phpcsstandards/phpcsdevtools",
  "type" : "phpcodesniffer-standard",
  "require" : {
      "php" : ">=5.4",
      "squizlabs/php_codesniffer" : "^3.1.0",
      "dealerdirect/phpcodesniffer-composer-installer" : "^0.4.1 || ^0.5 || ^0.6.2 || ^0.7"
  },
  "require-dev" : {
      "roave/security-advisories" : "dev-master",
      "phpunit/phpunit" : "^4.5 || ^5.0 || ^6.0 || ^7.0 || ^8.0 || ^9.0",
      "php-parallel-lint/php-parallel-lint": "^1.0",
      "php-parallel-lint/php-console-highlighter": "^0.5",
      "phpcsstandards/phpcsdevcs": "^1.1.1",
      "phpcsstandards/phpcsutils" : "^1.0"
  },
  "bin": [
      "bin/phpcs-check-feature-completeness"
  ],
  "minimum-stability": "dev",
  "prefer-stable": true
}

Running composer install results in the following error output:

Composer version 1.10.12 2020-09-08 22:58:51

Loading composer repositories with package information
Updating dependencies (including require-dev)

  [RuntimeException]
  Could not load package phpcsstandards/phpcsdevtools in http://repo.packagist.org: [UnexpectedValueException] Could not parse version constraint @dev: Invalid version string "@dev"

  [UnexpectedValueException]
  Could not parse version constraint @dev: Invalid version string "@dev"

Additional information

• The thing which boggles me is that none of the version constraints in this project uses @dev, so I can't pinpoint the problem.
• I've run composer install/composer update on nearly all of the individual dependencies of the project (save for roave/security-advisories and phpunit/phpunit) and they all install without problems.
• Of the projects which have a dependency on phpcsstandards/phpcsdevtools, three are running into problems with the above mentioned error: wp-coding-standards/wpcs, phpcsstandards/phpcsextra and yoast/yoastcs.
• However, and that is the part which I find strangest, two others don't run into any problems: phpcompatibility/php-compatibility and wptrt/wpthemereview
• For the five above mentioned projects, the dependency setup is nearly the same

Hi, some noob doubt about the "~" operator, it need to consider the bugfix level ? for example:

~1.3.1: >=1.3.1.0-dev <2.0.0.0-dev

Or only consider the second level ?

~ 1.3.1: >=1.3.0.0-dev < 2.0.0.0-dev

I just tried to use the getLowerBound and getUpperBound methods of the Constraint classes I received from MultiConstraint::getConstraints and got some unexpected results when testing the following version string ^1.5|^2.0.
It has two constraints reporting bounds from 1.5 to infinity and 0.0 to 3.0.
I understand why this is happening there and guess it is already known. If this can't be fixed easily it would from my point of view be better to throw an exception than to return wrong version informations.

A constraint should provide a way to retrieve its lower and upper boundaries.

For example ^5.1.3 should return 5.1.3.0 as the lower boundary and 5.99999.99999.99999 as the upper boundary. The exact number of 9 digits and number of version digits needs to match what Composer uses.

Need to review how suffixes like -dev1/0 or -pl99999 would need to be treated here.

1.0.0-x.7.z.92 is not recognised as a valid version. But based on the spec this is legal.

Based on https://semver.org/

A pre-release version MAY be denoted by appending a hyphen and a series of dot separated identifiers immediately following the patch version. Identifiers MUST comprise only ASCII alphanumerics and hyphen [0-9A-Za-z-]. Identifiers MUST NOT be empty. Numeric identifiers MUST NOT include leading zeroes. Pre-release versions have a lower precedence than the associated normal version. A pre-release version indicates that the version is unstable and might not satisfy the intended compatibility requirements as denoted by its associated normal version. Examples: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92.

Bit of a support request here.

In MediaWiki, we're currently doing if version a !== version b, complain. Where one version is the one defined in composer.json file, and the other is the version of the dependency.

The downstream issue I filed is https://phabricator.wikimedia.org/T141225

The problem is that 1.6.1 does not equal ~1.6

I thought there'd be something we could use in the semver library, but I feel I'm coming up short, without looking for special characters, and doing different sorts of comparisons. What I hoped might work, would be something like the below, swapping !== for ! equalsTo, but it doesn't.

diff --git a/maintenance/checkComposerLockUpToDate.php b/maintenance/checkComposerLockUpToDate.php
index 9ec61dc..6d1ad44 100644
--- a/maintenance/checkComposerLockUpToDate.php
+++ b/maintenance/checkComposerLockUpToDate.php
@@ -2,6 +2,8 @@

 require_once __DIR__ . '/Maintenance.php';

+use Composer\Semver\Comparator;
+
 /**
  * Checks whether your composer-installed dependencies are up to date
  *
@@ -43,7 +45,7 @@ class CheckComposerLockUpToDate extends Maintenance {
                $installed = $lock->getInstalledDependencies();
                foreach ( $json->getRequiredDependencies() as $name => $version ) {
                        if ( isset( $installed[$name] ) ) {
-                               if ( $installed[$name]['version'] !== $version ) {
+                               if ( !Comparator::equalTo( $installed[$name]['version'], $version ) ) {
                                        $this->output(
                                                "$name: {$installed[$name]['version']} installed, $version required.\n"
                                        );

Am I just being stupid, and as such, is there a way to get it to do what I want? Basically, a version comparison, where one version may or may not have next significant release operators etc

Thanks in advance!

I am trying to use satisfiedBy to parse php dependencies, somehow I found an error like this:

library name: aarontong00/zippy
version:1.3

the dependencies of this library version is:

php: >=5.5
doctrine/collections: v1.4.0
symfony/filesystem: ^2.0.5 || ^3.0
symfony/process: ^2.1 || ^3.0 || ^4.0
symfony/polyfill-mbstring: ^1.3

For all versions of symfony/filesystem, I parsed the deps like this:

function check($req, $v)
{
    $satisfies = array();
    $vers = explode('|', $v);
    $satisfies = Semver::satisfiedBy($vers, $req);
    echo implode('|', $satisfies);
}
check('^2.0.5 || ^3.0', '3.3.x-dev|3.4.x-dev|3.4.32|dev-1');

The output is 3.3.x-dev|3.4.x-dev|3.4.32
but when I used composer update to install this aarontong00/zippy:1.3, the installed version of
symfony/filesystem is 3.4.32. So I think the output of satisfiedBy shouldn't include the
dev versions if the dev tags are not considered when install.

with the recent release its no longer possible to have a dev-trunk constraint (which we have from SVN times) but actually use a dev-master branch. it seems dev-trunk was a alias for dev-master which is no longer the case.

reproduced this issue with composer v2. is this a known/intentional BC break?

Instead of directly matching a constraint, implement functions on the constraints to generate code which verifies if a particular version number matches the constraint. In particular the multi constraint should optimize the expression by checking only the minimally necessary boundaries on a conjunctive constraint.

This is useful to generate code in composer install which later gets verified at runtime and needs to be very fast.

Composer 2 testing for Drupal 8.9 / 9.0 dev is in progress.

It might be possible to release a version of Drupal compatible with Composer 2 prior to the release of Composer 2. However, drupal/core depends on composer/semver, and we can't increase our dependency here to 2.x until there's a stable 2.0.0. (Drupal requires composer/composer for testing, so we need to use a composer/semver that is compatible with Composer.)

We can probably still release versions of our Composer plugins that are compatible with Composer 2 in advance even without the new version of composer/semver, which is the important part. If it's possible to tag a stable composer/semver in advance of the stable Composer 2.x, though, it would make things a touch more convenient.

We're currently using the equivalent of this line of code :

$satisfies = Semver::satisfies(phpversion(), '^7.2');

Issue is, our CI returns this php version (which is technically invalid I know) : 7.2.34-18+ubuntu20.04.1+deb.sury.org+1. So when running Unit/Feature Tests CI fails with this error :

Invalid version string "7.2.34-18+ubuntu20.04.1+deb.sury.org+1"  

VersionParser::normalize basically ends as 7.2.34-18 instead of 7.2.34.

I know technically it's the PHP version that is at fault here, but this is a common naming scheme from packaged provided PHP on some distro. Even if we were to change our test to go around, the issue would still arise for some users when using this code on their server with this kind of version scheme (and somehow Composer itself doesn't complain about it...?)

The implementation of the version comparison of the Constraint will fails when using a sub class of Constraint.

For instance if a 3rd party code still uses the Composer\Package\LinkConstraint\VersionConstraint class which is a subclass. It will fail because the $provider->version property is private and is only accessible from the Constraint class itself.

Related issue contao-community-alliance/composer-plugin/issues/44.

When analyzing a composer.lock file sent by customer, I discovered this package:

      {
           "name": "foo/bar",
           "version": "8.x-1.x-dev",
           "...": "truncated"
       }

When parsing the version, Semver throws an UnexpectedValueException.

note: This exception, is also thrown when running $composer->getLocker()->getLockedRepository() when the ArrayLoader is loading the package.

So, I wonder, if this is a legitimate version, and if we should patch Semver?

ref: composer/composer#5617

Given

{
    "require": {
        "jms/serializer": "~0.13|~1.0 !=1.3.1"
    }
}

version 1.3.1 is not excluded.

My composer.json:

{
    "require": {
        "authorizenet/authorizenet": "^1.9.7"
    }
}

Output of composer diagnose:

Checking platform settings: OK
Checking git settings: OK
Checking http connectivity to packagist: OK
Checking https connectivity to packagist: OK
Checking github.com rate limit: OK
Checking disk free space: OK
Checking pubkeys: 
Tags Public Key Fingerprint: 57815BA2 7E54DC31 7ECC7CC5 573090D0  87719BA6 8F3BB723 4E5D42D0 84A14642
Dev Public Key Fingerprint: 4AC45767 E5EC2265 2F0C1167 CBBB8A2B  0C708369 153E328C AD90147D AFE50952
OK
Checking composer version: OK
Composer version: 1.10.12
PHP version: 7.4.9
PHP binary path: /usr/bin/php7.4
OpenSSL version: OpenSSL 1.1.1g  21 Apr 2020

When I run this command:

composer update

I get the following output:

Loading composer repositories with package information
Updating dependencies (including require-dev)

                                                                               
  [RuntimeException]                                                           
  Could not load package authorizenet/authorizenet in http://repo.packagist.o  
  rg: [UnexpectedValueException] Could not parse version constraint xsd2php-d  
  ev as 0.18.0: Invalid version string "xsd2php-dev as 0.18.0" in "xsd2php-de  
  v as 0.18.0", the alias source must be an exact version, if it is a branch   
  name you should prefix it with dev-                                          
                                                                               

                                                                               
  [UnexpectedValueException]                                                   
  Could not parse version constraint xsd2php-dev as 0.18.0: Invalid version s  
  tring "xsd2php-dev as 0.18.0" in "xsd2php-dev as 0.18.0", the alias source   
  must be an exact version, if it is a branch name you should prefix it with   
  dev-                                                                         
                                                                               

update [--prefer-source] [--prefer-dist] [--dry-run] [--dev] [--no-dev] [--lock] [--no-custom-installers] [--no-autoloader] [--no-scripts] [--no-progress] [--no-suggest] [--with-dependencies] [--with-all-dependencies] [-v|vv|vvv|--verbose] [-o|--optimize-autoloader] [-a|--classmap-authoritative] [--apcu-autoloader] [--ignore-platform-reqs] [--prefer-stable] [--prefer-lowest] [-i|--interactive] [--root-reqs] [--] [<packages>]...

And I expected this to happen:

successful installation of packages

Notes:

This started happening when I updated my composer to version 1.10.12. I had to delete all composer caches while doing it.