Composer "Could not parse version constraint {version}" error

This apply to all version, giving same error with ^2.0

composer require 'drupal/campaignmonitor:^2.0'

Yeah experiencing same issue by just trying to update my lock file.
Seem to be again the issue like described in #2906369: Composer issue for campaignmonitor?

@tim-diels I'm having same issue too just trying to remove another drupal module. Also, I've found same issue already fixed in a previous version but the fix is not working anymore:
https://www.drupal.org/project/campaignmonitor/issues/2887580

There is a commit from yesterday on the json file.
https://git.drupalcode.org/project/campaignmonitor/-/blob/9afe72d6a0549c...
They have added this line:
"drupal/core": "^8 || ^9",

I'm experiencing this as well. I was only able to get rid of the error by manually removing the module.

Edit: I also removed composer.lock (and created a new one with composer update --lock).

Manually removing the module worked for me on composer install only. I cannot update other package. This will break deployment that use composer to build.

You are not allowed to make such mistakes. The composer.json needs to be valid at all times. Once a bad composer.json is released, you are in trouble. The module can no longer be used with composer.

Try an issue with https://www.drupal.org/project/project_composer requesting a manual fix. You are not the first one/only one having experienced this. You might want to check the issue queue for similar issues.
Found one: https://www.drupal.org/project/project_composer/issues/3102755
Generic fix: https://www.drupal.org/project/project_composer/issues/3076342

The only alternative I know is to abandon this project and move to a new namespace. Obviously, without errors in composer.json.

Also suggest to make `composer validate` part of your make release or commit strategy.

@mmjvb: I'm not the maintainer of this module, but it seems rather drastic to have to create a completely new namespace? Also, it seems like a rather big security issue that existing modules may break composer deployments simply by committing an erroneous composer.json. I don't fancy the idea the my composer deployments (usually locked to specific module versions) will break when a commit occurs (especially when considering automatic build schemes and kubernetes etc).

Looks like the the core issue needs to be addressed in the project_composer queue:
#3076342: Filter out bad version constraints

In 2017, the composer file has changed from campaignmonitor/createsend-php": "{version}" to campaignmonitor/createsend-php": "^5.0.2". Why does it now lead to broken builds?

I cannot add/update any module now in my project. Any tips on how to ignore/fix this?

@BarisW: see comment #6, that worked for me.

What I don't really understand is why composer.json seems to be valid once you test the module separately, it is running any composer command inside the module path without any error. Also, the error show by composer says '......Invalid version string "{version}' the last module version doesn't contain {version} on the composer.json file.

Yeah, I noticed that too. This error was already fixed in 2017: https://git.drupalcode.org/project/campaignmonitor/commit/1d1db8c
So why it's popping up now: no clue :(

@BarisW Could be composer try to download a previous module version for some reason even we are asking ^2.0. It doesn't sound logical TBH.

Seems that composer is not installing the right version because it doesn't match with drupal core requirements. The line they committed 2 days ago, I'm not quite sure because other modules are asking the same drupal/core requirements for the compatibility with drupal 9 and are working properly:

https://www.drupal.org/node/3127396

Something similar happened with migrate Upgrade module:
https://www.drupal.org/project/migrate_upgrade/issues/3008682#comment-12...

Maintainers fixed it, removing the last change. Composer is not failing anymore.

As per my discovery on #3127396: Drupal 9 compatibility:

Composer Json manifest contains errors passed from poorly defined composer.json for older versions.
Seems like those errors didn't kicked in until semantic versioning was switch on.

https://packages.drupal.org/8/drupal/campaignmonitor%248295169748a199564...
{version} was placed in composer.json for the following releases

• 1.0.0-alpha2
• 1.0.0-beta1

Try un-publishing those releases. Sounds like those database edits are reverted, suggest to request @mixologic to do them again.

@VladimirAus after last commit is failing again, now composer run to install/update/remove other modules, but not able to install cmapaignmonitor, same error.

@lcontreras: as mentioned in #3127396: Drupal 9 compatibility - commits won't affect the issue. Someone with admin permissions needs to unpublish the following releases:

• 1.0.0-alpha2
• 1.0.0-beta1

and regenerate JSON manifest

I asked for help on slack.
Unfortunately we can only wait.

@VladimirAus okay thanks for the effort :)

@VladimirAus whom do we need to get to do this?

@aburrows I created issue #3132985: Bad json manifest causes composer "Could not parse version constraint {version}" error in Drupal Infrastructure (recommended by @xjm on Slack).

Can someone point out how to fix this? Removing and re-installing the module does not work, still get the error mentioned by OP.
I'm unable to do anything composer related...

Several solutions have been pointed out already, unfortunately none of them available as of now. There is nothing you can do to fix it, it requires others to do something.

You could temporarily not use composer for this module. Replace it with campaignmonitor/createsend-php as that is a requirement. Probably needs manual edit of composer.json/composer.lock to remove it. Then either manually extend or use Ludwig for drupal/campaignmonitor till issue resolved.

Tried to fix it at the source: vendor/composer/semver/src/VersionParser.php

private function parseConstraint($constraint)
    {
        if ( '{version}' == $constraint ) { $constraint = '{^1@alpha}'; }

but it didn't workout.

Also tried to manipulate the cached information. Unfortunately, that keeps being refreshed. Maybe that is because I didn't have it installed already, the information is in: provider-drupal$campaignmonitor.json, not in something like drupal-provider-2020-2.json.

EDIT
The composer.phar includes semver/src/VersionParser.php. Either extract the phar or add your change to it.

Or maybe treat this module as a custom module for now? Exclude it from .gitignore and commit it into my repo...

I solved it like this:

• Remove all campaignmonitor references from composer.json and composer.lock
• Execute composer install, the module and library will be removed
• Add following lines to your .gitignore file:
  

  /web/modules/contrib/*
  !/web/modules/contrib/campaignmonitor

• Execute composer require campaignmonitor/createsend-php:^5.1.3 to install the 3rd party library again
• Download the campaignmonitor module to /web/modules/contrib/campaignmonitor and enable it

These steps will remove campaignmonitor from your composer managed modules and thus it will be treated as a custom module (it will be added to your git repository). When this problem is fixed, just reverse these steps and require the module as normal

Not really a need for treating it as a custom module. There is nothing wrong with the current state of the module. It is the meta data provided that is not liked by composer. That meta data is corrected in newer releases. Unfortunately, it is not allowed to fix old meta on d.o. Extending like you did before composer is enough.

EDIT
Manually extending instead of using composer doesn't make it a custom module, it remains a contrib module till you customize it.

I know there is nothing wrong with the module itself, but nevertheless, it blocks our complete development flow, so we need to get this out of composer until this issue is fixed.
So basically, for the time being, it is required to treat this as a custom module (except if you do not want to update or install any modules through composer of course)

Maintainers might want to investigate Narrowsparc-Automatic

It complements composer and should allow restricting versions. That way you could skip the bad versions.

Consumers might be interested in Studio to overrule the facade from d.o. for this module. Rather than manual downloading, it continues to use composer, but prefers a local version to the one from d.o.

@mmjvb Thanks for this suggestion.

My first read of the automatic plugin gave me the impression your app (Drupal module) would need to have a configuration file. Hence I targeted it for the maintainers of the module. It looks like you can use it without adding anything to your module. See
https://github.com/narrowspark/automatic#automatic-extends-composer

This makes it interesting for consumers as well. Sounds like just requiring automatic for your site and adding the extra key for skipping the bad releases should solve the issue.

EDIT: Unfortunately not

Those running Composer v2 could add a package repository. In v2 repositories are authoritative by default. That means it stops looking when found. It no longer scans all repositories for the same same package.

#3076342: Filter out bad version constraints has been deployed to Drupal.org and I re-processed the Composer metadata for this project. I expect this will resolve the issue.

Confirmed:

docker@cli:/var/www$ composer require drupal/campaignmonitor:^2@alpha
./composer.json has been updated
> DrupalProject\composer\ScriptHandler::checkComposerVersion
Loading composer repositories with package information
Updating dependencies (including require-dev)

Prefetching 2 packages 🎶 💨
  - Downloading (100%)

Package operations: 2 installs, 0 updates, 0 removals
  - Installing campaignmonitor/createsend-php (v5.1.3): Loading from cache
  - Installing drupal/campaignmonitor (2.0.0-alpha1): Loading from cache
Package container-interop/container-interop is abandoned, you should avoid using it. Use psr/container instead.
Package jakub-onderka/php-console-color is abandoned, you should avoid using it. Use php-parallel-lint/php-console-color instead.
Package jakub-onderka/php-console-highlighter is abandoned, you should avoid using it. Use php-parallel-lint/php-console-highlighter instead.
Package zendframework/zend-diactoros is abandoned, you should avoid using it. Use laminas/laminas-diactoros instead.
Package zendframework/zend-escaper is abandoned, you should avoid using it. Use laminas/laminas-escaper instead.
Package zendframework/zend-feed is abandoned, you should avoid using it. Use laminas/laminas-feed instead.
Package zendframework/zend-stdlib is abandoned, you should avoid using it. Use laminas/laminas-stdlib instead.
Writing lock file
Generating autoload files
4 packages you are using are looking for funding.
Use the `composer fund` command to find out more!
Automatic operations: 0 package
Writing automatic lock file
> DrupalProject\composer\ScriptHandler::createRequiredFiles

[!] Audit Security Report: 4 vulnerabilities found - run "composer audit" for more information
docker@cli:/var/www$

Thanks everyone!

Thanks for solving this :)