Could not parse version constraint @dev: Invalid version string "@dev"

[jrfnl]

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

[Seldaek]

The @dev constraint appears in https://packagist.org/packages/phpcsstandards/phpcsdevtools#dev-test/phpcompat-recursive-dep

phpcompatibility/php-compatibility: ^9.0.0 || @dev

Please don't remove it for now though, but really this is a weird constraint as it literally equals to ^9.0 OR anything => anything. So *@dev would be the smallest constraint here. Most likely requiring ^9.0@dev would make more sense, as it allows any 9.x version, including dev ones, but does not allow 10.x or 8.x for example.

[Seldaek]

The reason it fails I assume is that when combined with ||, @dev gets stripped first and it ends up parsing '' as a constraint which fails, but if you only use @dev as the full constraint then it notices and replaces it by a * when removing the @dev flag. Anyway I will fix somehow..

[jrfnl]

@Seldaek

The @dev constraint appears in https://packagist.org/packages/phpcsstandards/phpcsdevtools#dev-test/phpcompat-recursive-dep

Oh cricky... that was one of my old attempts to solve the recursive dependency issue you helped me with the other week.

The branch was pushed at the time (a year ago) as I needed it available for tests with the other repos at that time, but I have since removed it (some time last week), now I have it properly solved/fixed and IIRC I have removed every one of the other test branches I had related to my earlier attempts in other repos as well.

So, how come Packagist is still showing that branch ? Do removed branches not get scrubbed automatically ?

I never even thought to look for weird dependency constraints in branches which are no longer available and never made it into a develop/stable branch, let alone a release.

Thank you so much for finding the problem and fixing it. I imagine there may be more people with weird versions in temporary/test branches, so at least it's one less thing which can go wrong.

[jrfnl]

Oh and another question: why did it break with three out of five repos using this dependency, but not for the other two ?

[stof]

So, how come Packagist is still showing that branch ? Do removed branches not get scrubbed automatically ?

IIRC, they get removed only after 1 week, because in the past (when starting packagist years ago), the github API was a lot less reliable and could result into branches being missed during an update while they were still there.

[stof]

note that as a maintainer, you can force the removal of a version on packagist (if the version you remove still exists in your github repo, that's silly because the next update will recreate it. but it is useful to delete a version from a removed branch in a faster way if it causes issues)

[jrfnl]

as a maintainer, you can force the removal of a version on packagist

I'm aware of that, but would hope I wouldn't have to do that manually for the hundreds/thousands of PR feature branches I pull to various repos, though from your comment I gather they get removed after a week, so that branch should automatically be removed either today or tomorrow.

I hadn't touched it manually for now as @Seldaek asked above not to:

Please don't remove it for now though

[Seldaek]

Ah feel free to remove it now :) as for why it broke with some, it might be because not all versions were loaded depending on context, where the package was required etc

[jrfnl]

@Seldaek Thanks for your response and thanks again for getting this fixed.

I've (manually) removed the problem branch now from Packagist.

as for why it broke with some, it might be because not all versions were loaded depending on context, where the package was required etc

As far as I can see, the context was the same for all: none of these repos have a committed composer.lock, so I tested it locally for each of them by deleting any existing vendor directory and composer.lock file and then running composer update.