Add support for Composer v2

mcaskill commented 3 years ago

Latest Update 2021-01-25 14:25 EST

Notes:

Avoid unnecessary issue bumping. Please test this pull request and report issues or approve working state.
See comment.
Stability of this pull request's changeset needs additional testing from the community, such as unintentional updates upon requiring this plugin.
See comment.
Project is stuck in the process of transferring ownership to a new team within the Wikimedia Foundation.
See comment.
Since v1.4 of the plugin does not support Composer v2, the plugin is ignored when updating to v1.5. As a result, Composer is unaware of the merged dependencies and removes them. Either update the plugin with Composer v1 first or run composer update again.
See comment.
Unintentional lock file updates caused by isFirstInstall() on Composer v2. Listening only to post-update-cmd instead of post-install-cmd might be more sensible. See comment and followup.
Please be patient, we don't want to push broken changes.

How to test:

{
    "repositories": [
        {
            "type":"vcs",
            "url":"https://github.com/mcaskill/composer-merge-plugin"
        }
    ],
    "require": {
        "wikimedia/composer-merge-plugin": "dev-feature/composer-v2 as 1.5.0"
    }
}

Tasks:

[x] Find alternative to install inherited dependencies without affecting locked dependencies.
See comment #1, comment #2, comment #3.
[x] Rebase to include #197 and #199
[x] Update port of MultiConstraint to latest version of composer/semver.
See comment.
[x] Method Factory::getLockFile() does not exist in Composer 1.
See comment.

Replaces #187, #185, as fix for #184 (as per composer/composer#8726)

I've tested using the example and the unit tests and it works in Composer v1 and v2.

This alternative proposal forgoes PRE_DEPENDENCIES_SOLVING entirely to avoid over-complicating the codebase and streamline the plugin's merge logic.

The issue with the previous attempts (as well as attempts on other plugins) stems from a miscommunication from the Composer team of the major difference in how v1 and v2 resolve and install dependencies.

[…] Roughly speaking:

Composer v1: Composer resolves dependencies (dispatching *_DEPENDENCIES_SOLVING), iterates packages (while dispatching PRE_PACKAGE_* before PRE_FILE_DOWNLOAD), then finally writes the lock file.

Composer v2: Composer resolves dependencies (dispatching PRE_POOL_CREATE), writes the lock file, dispatches PRE_OPERATIONS_EXEC, downloads the packages (while dispatching PRE_FILE_DOWNLOAD), then iterates packages (while dispatching PRE_PACKAGE_*).

In particular, people are assuming that PRE_OPERATIONS_EXEC is a replacement for PRE_DEPENDENCIES_SOLVING since they are dispatched in a similar-looking routine. The closest event to the latter would actually be PRE_POOL_CREATE. — composer/composer#8726

Back to my proposal.

Currently, the use of PRE_DEPENDENCIES_SOLVING in the plugin is used to inject duplicate requirements (usually with a different version constraints) into the solver (while distinguishing between require and require-dev).

What I propose replaces the duplicate links tracking in ExtraPackage by back porting Composer 2's new static MultiConstraint::create() method which can be used to resolve complex-constraints early on. In turn, this makes the need for PRE_DEPENDENCIES_SOLVING obsolete.

I hope this PR will, at the very least, help to figure out how to support Composer v2.

LukeTowers commented 3 years ago

@tobias-kuendig could you test this with October & Composer 1.0 & 2.0?

mcaskill commented 3 years ago

Note: I last tested these changes with Composer v1.10.15 / v2.0.2. I do am unaware if it works in latest versions.

atapatel commented 3 years ago

When will it release for composer 2.0 ?

Dmi3yy commented 3 years ago

are looking forward to

terabytesoftw commented 3 years ago

Thanks for the huge work, any ideas when it will merge.

sebschaefer commented 3 years ago

Tested with Composer 2.0.3. Works for me. Thanks!

ivi3 commented 3 years ago

@sebschaefer how you solved that? which version do u use?

mlocati commented 3 years ago

You can check this PR in your projects by requiring wikimedia/composer-merge-plugin:dev-feature/composer-v2 and adding the https://github.com/mcaskill/composer-merge-plugin.git vcs repository to your composer.json file.

I just checked this with concrete5 and this PR fixes the issue.

FlorentTorregrosa commented 3 years ago

Hello,

Thanks to everyone involved in this PR.

leoloso commented 3 years ago

This PR worked for me too, thanks!

prudloff-insite commented 3 years ago

This PR seems to work mostly correctly. However, I am getting this error when installing with Composer 1.10.1:

PHP Fatal error:  Uncaught Error: Call to undefined method Composer\Factory::getLockFile() in /mnt/data/workspace/drupal_d9/vendor/wikimedia/composer-merge-plugin/src/MergePlugin.php:323
Stack trace:
#0 [internal function]: Wikimedia\Composer\MergePlugin->onPostInstallOrUpdate()
#1 /usr/share/php/Composer/EventDispatcher/EventDispatcher.php(164): call_user_func()
#2 /usr/share/php/Composer/EventDispatcher/EventDispatcher.php(96): Composer\EventDispatcher\EventDispatcher->doDispatch()
#3 /usr/share/php/Composer/Installer.php(338): Composer\EventDispatcher\EventDispatcher->dispatchScript()
#4 /usr/share/php/Composer/Command/InstallCommand.php(122): Composer\Installer->run()
#5 /usr/share/php/Symfony/Component/Console/Command/Command.php(255): Composer\Command\InstallCommand->execute()
#6 /usr/share/php/Symfony/Component/Console/Application.php(934): Symfony\Component\Console\Command\Command->run()
#7 /usr/share/php/Symfony/Component/Console/Application.php(273): Symfony\Component\Console\Application->doRunCommand()
#8 /usr/share in /mnt/data/workspace/drupal_d9/vendor/wikimedia/composer-merge-plugin/src/MergePlugin.php on line 323

Fatal error: Uncaught Error: Call to undefined method Composer\Factory::getLockFile() in /mnt/data/workspace/drupal_d9/vendor/wikimedia/composer-merge-plugin/src/MergePlugin.php:323
Stack trace:
#0 [internal function]: Wikimedia\Composer\MergePlugin->onPostInstallOrUpdate()
#1 /usr/share/php/Composer/EventDispatcher/EventDispatcher.php(164): call_user_func()
#2 /usr/share/php/Composer/EventDispatcher/EventDispatcher.php(96): Composer\EventDispatcher\EventDispatcher->doDispatch()
#3 /usr/share/php/Composer/Installer.php(338): Composer\EventDispatcher\EventDispatcher->dispatchScript()
#4 /usr/share/php/Composer/Command/InstallCommand.php(122): Composer\Installer->run()
#5 /usr/share/php/Symfony/Component/Console/Command/Command.php(255): Composer\Command\InstallCommand->execute()
#6 /usr/share/php/Symfony/Component/Console/Application.php(934): Symfony\Component\Console\Command\Command->run()
#7 /usr/share/php/Symfony/Component/Console/Application.php(273): Symfony\Component\Console\Application->doRunCommand()
#8 /usr/share in /mnt/data/workspace/drupal_d9/vendor/wikimedia/composer-merge-plugin/src/MergePlugin.php on line 323

(Only the first time, the next composer install don't trigger the error.)

mcaskill commented 3 years ago

[…] I am getting this error when installing with Composer 1.10.1:

@prudloff-insite Thanks, I'll check this out.

prudloff-insite commented 3 years ago

Also it looks like the plugin now runs composer update after the first install? This is a problem when running composer install on a CI. We expect the locked dependencies to be installed as is and not everything to be updated.

mcaskill commented 3 years ago

Also it looks like the plugin now runs composer update after the first install? This is a problem when running composer install on a CI. We expect the locked dependencies to be installed as is and not everything to be updated.

@prudloff-insite Good point! I had a feeling there was some flaw.

When the plugin is first installed, it triggers a second install / update.

In Composer 2, I'm forcing an update to add the inherited dependencies to the lock file but this is clearly an issue with existing root dependencies that might not want to be updated.

I'll try to look into it soon. If you have any suggestions, I'm all ears.

prudloff-insite commented 3 years ago

Would it be possible to run composer update only on dependencies from the merged file?

Or at least add a flag that we can use on the CI to tell it not to update the lock file.

mcaskill commented 3 years ago

Would it be possible to run composer update only on dependencies from the merged file?

Or at least add a flag that we can use on the CI to tell it not to update the lock file.

@prudloff-insite There must be a way to handle this. I need to look into this. There's been quite a few changes in Composer since late September (when I initially put together this proposal).

mcaskill commented 3 years ago

I'm reading through my code and I'm seeing a potential flaw in my logic related to merging extra requirements.

If someone were to add/remove/change the requirements of a nested composer file and triggered an install/update of an already installed root composer file, I think the root package will fail to alter its lock file and install/remove/update the changed nested requirements.

If people can do some further testing of this branch, it would be much appreciated.

LukeTowers commented 3 years ago

@mcaskill I think that behaviour might have already existed in this plugin, I've noticed a few times when changing October CMS plugins that I load into a October CMS project that sometimes I'll have to run composer update twice to get it to fully cleanup the dependencies that were only included by those plugins, hence nested requirements.

peter-mw commented 3 years ago

I found a working version here https://github.com/TopFloorTech/composer-merge-plugin/tree/composer-2-fix

mcaskill commented 3 years ago

I found a working version here https://github.com/TopFloorTech/composer-merge-plugin/tree/composer-2-fix

That fork is simply a merge of this pull request without additional changes (comparison).

LukeTowers commented 3 years ago

@reedy @bd808 what's required to get this merged?

bd808 commented 3 years ago

@reedy @bd808 what's required to get this merged?

I have been trying to hand maintenance of composer-merge-plugin over to a team within the Wikimedia Foundation for several months. Unfortunately that hand off is taking far longer than I had hoped. This PR is sort of being held hostage (by me) as a forcing function to complete the transition. I will not at all block any other person with merge rights in this repo from accepting the PR and tagging a new release, but I will not be doing it personally.

peter-mw commented 3 years ago

@mcaskill can you merge this PR https://github.com/mcaskill/composer-merge-plugin/pull/1 to your repo

LukeTowers commented 3 years ago

@bd808 is the Wikimedia Foundation still interested in maintaining this plugin? If we absolutely have to maintain it at @octobercms we will, given that we use it extensively but of course it would be better if it stayed with wikimedia, so long as they're actually able to maintain it.

mcaskill commented 3 years ago

@mcaskill can you merge this PR mcaskill#1 to your repo

I have not merged it yet because I am uncertain of its stability when it comes to extended usage as well as first install.

For example, upon first install of the plugin a secondary run of composer update is performed which will target all packages which is might be undesired.

Also, I have not tested subsequent updates to root, nested, or merged packages.

bd808 commented 3 years ago

@bd808 is the Wikimedia Foundation still interested in maintaining this plugin?

I sure hope so. :) This plugin was invented to help folks who are managing MediaWiki deployments and using Composer to provision MediaWiki Extensions. The plugin is actively used not only by many so called "third-party" deployments of MediaWiki, but also by the CI systems and some local development environments for MediaWiki at the Wikimedia Foundation.

LukeTowers commented 3 years ago

@bd808 @reedy @mcaskill What is needed in order to push this through to completion? Do we need to put up some money to move this forward? This is actively blocking new installs of October CMS via composer when using composer 2.0.

mlocati commented 3 years ago

This is actively blocking new installs of October CMS via composer when using composer 2.0.

And concrete5 CMS...

Dmi3yy commented 3 years ago

And Evolution CMS

louis-cuny commented 3 years ago

And Drupal 8 with webform libraries

lcharette commented 3 years ago

And UserFrosting...

If testing / manpower is required to get this merged, let us know too.

Seldaek commented 3 years ago

I am pretty sure you can all try it out and make sure it works with your respective CMSs/use cases. The sooner issues get reported the better.

Using something like this in your composer.json should let you try out @mcaskill 's fork/feature branch.

{
    "repositories": [
        {"type":"vcs", "url":"https://github.com/mcaskill/composer-merge-plugin"}
    },
    "require": {
        "wikimedia/composer-merge-plugin": "dev-feature/composer-v2 as 1.5.0"
    }
}

reedy commented 3 years ago

And basically replying "me too" doesn't really help.

As pointed out, there is a patch, it is being worked on... but there's some issues that have seemingly come up from later changes in the composer 2.x release cycle. Helping test the patch helps everyone, and has been said multiple times. For example, if we'd merged this based on earlier patches, and made a release, there's seemingly use cases that would have still been broken.

An option (for now) is to just document your application only supports composer 1.x. We have done that for MediaWiki. I doubt that at this stage there's many people that have to use composer 2.x; the fact that the merge-plugin doesn't work on it seems to just confirm that, as you've got an incompatible mix of software, so you can't require composer 2.x features and composer-merge-plugin as both compulsory.

It's similarly documented at https://github.com/composer/composer/issues/9329 (ie how to downgrade; and downgrading is easy) too as a way forward

I know people get upgrade-itis (plus composer does like to warn there's an upgrade available), but if you document it doesn't work, and they don't read them... You can just point them at it ;)

AIUI, composer 1.x is still supported, and presumably will be to some extent for a while

Seldaek commented 3 years ago

AIUI, composer 1.x is still supported, and presumably will be to some extent for a while

Emphasis on to some extent, we would really like for most people to migrate to v2 ASAP - it's bound to happen anyway and it makes everyone's life easier once the transition is complete, so might as well get it over with :) So yes we will keep supporting 1.x with critical fixes, but it's not receiving any more than that.

SebastiaanKloos commented 3 years ago

I'm using the patch on a few production sites and can confirm it works for October CMS projects 👍

reedy commented 3 years ago

AIUI, composer 1.x is still supported, and presumably will be to some extent for a while

Emphasis on to some extent, we would really like for most people to migrate to v2 ASAP - it's bound to happen anyway and it makes everyone's life easier once the transition is complete, so might as well get it over with :) So yes we will keep supporting 1.x with critical fixes, but it's not receiving any more than that.

Oh for sure. I'm certainly not saying never upgrade :).

But when you (composer/upstream) know some well used plugins don't work yet, but are actively being worked on (not abandoned etc)... And it's only a month or so from release, I'd hope you wouldn't be dropping the support too quickly :), at least, not until stable releases are out.

(Also, thanks for helping CR the PR 👍 )

alexwenzel commented 3 years ago

"require": {
        "wikimedia/composer-merge-plugin": "dev-feature/composer-v2 as 1.5.0",
    },
"repositories": [
        {
            "type": "vcs",
            "url": "https://github.com/mcaskill/composer-merge-plugin"
        }
    ],

this fixed my october cms composer.json. thank you sir.

Jedliu commented 3 years ago

This works for Apiato. Thank you!

lcharette commented 3 years ago

And basically replying "me too" doesn't really help.

As pointed out, there is a patch, it is being worked on... but there's some issues that have seemingly come up from later changes in the composer 2.x release cycle. Helping test the patch helps everyone, and has been said multiple times. For example, if we'd merged this based on earlier patches, and made a release, there's seemingly use cases that would have still been broken.

An option (for now) is to just document your application only supports composer 1.x. [...]

Where do we stand 15 days later? I get saying "me too" won't probably help, but so does having to go through many repo to add the doc warning, having to handle our support chat for people who don't read the warning and add a fix so Travis don't actually use Composer 2...

We have report of the general fix working in some project. What are the other "issues that have seemingly come up from later changes in the composer 2.x"? Can we have details on that so we can't focus testing on this element? Any other testing element we need to focus on?

This PR is sort of being held hostage (by me) as a forcing function to complete the transition.

Is that still an issue? What can we do to help if it's the case ?

reedy commented 3 years ago

See the commits added after my comment? https://github.com/wikimedia/composer-merge-plugin/pull/189#commits-pushed-05b6bb0

reedy commented 3 years ago

So I don't remember where I read this, and didn't see it again with a quick look, but I think it was a comment by macskill... Questioning if this was a bug or similar

First run of composer update using composer 2.0 (specifically 2.0.8) and "dev-feature/composer-v2 as 1.5.0" results in all of the dependancies brought in via extra/merge-plugin/include (which are composer.json files themselves) originally by a composer 1.x version being removed and the merge plugin being updated.

Running it again immediately after brings them all back again...

reedy@ubuntu64-web-esxi:/var/www/wiki/mediawiki/core$ php ../composer-2.0.phar update
The "wikimedia/composer-merge-plugin" plugin was skipped because it requires a Plugin API version ("^1.0") that does not match your Composer installation ("2.0.0"). You may need to run composer update with the "--no-plugins" option.
> ComposerHookHandler::onPreUpdate
Loading composer repositories with package information
Updating dependencies                                 
Lock file operations: 0 installs, 1 update, 24 removals
  - Removing beberlei/assert (v3.3.0)
  - Removing brick/math (0.9.1)
  - Removing christian-riesen/base32 (1.3.2)
  - Removing defuse/php-encryption (v2.2.1)
  - Removing fgrosse/phpasn1 (v2.2.0)
  - Removing firebase/php-jwt (v5.2.0)
  - Removing jakobo/hotp-php (v1.0.1)
  - Removing lcobucci/jwt (3.4.1)
  - Removing league/event (2.2.0)
  - Removing league/oauth2-server (dev-v9.0.0-alpha a00cc3c)
  - Removing league/uri (6.4.0)
  - Removing league/uri-components (2.2.1)
  - Removing league/uri-interfaces (2.2.0)
  - Removing psr/http-factory (1.0.1)
  - Removing ramsey/collection (1.1.1)
  - Removing ramsey/uuid (4.1.1)
  - Removing spomky-labs/base64url (v2.0.4)
  - Removing spomky-labs/cbor-php (v2.0.1)
  - Removing symfony/process (v5.2.0)
  - Removing web-auth/cose-lib (v3.2.10)
  - Removing web-auth/metadata-service (v3.2.10)
  - Removing web-auth/webauthn-lib (v3.2.10)
  - Removing wikimedia/css-sanitizer (v2.0.1)
  - Removing wikimedia/equivset (1.4.0)
  - Upgrading wikimedia/composer-merge-plugin (v1.4.1 => dev-feature/composer-v2 a8c5a89)
Writing lock file
Installing dependencies from lock file (including require-dev)
Package operations: 0 installs, 1 update, 24 removals
  - Syncing wikimedia/composer-merge-plugin (dev-feature/composer-v2 a8c5a89) into cache
  - Removing wikimedia/equivset (1.4.0)
  - Removing wikimedia/css-sanitizer (v2.0.1)
  - Removing web-auth/webauthn-lib (v3.2.10)
  - Removing web-auth/metadata-service (v3.2.10)
  - Removing web-auth/cose-lib (v3.2.10)
  - Removing symfony/process (v5.2.0)
  - Removing spomky-labs/cbor-php (v2.0.1)
  - Removing spomky-labs/base64url (v2.0.4)
  - Removing ramsey/uuid (4.1.1)
  - Removing ramsey/collection (1.1.1)
  - Removing psr/http-factory (1.0.1)
  - Removing league/uri-interfaces (2.2.0)
  - Removing league/uri-components (2.2.1)
  - Removing league/uri (6.4.0)
  - Removing league/oauth2-server (dev-v9.0.0-alpha a00cc3c)
  - Removing league/event (2.2.0)
  - Removing lcobucci/jwt (3.4.1)
  - Removing jakobo/hotp-php (v1.0.1)
  - Removing firebase/php-jwt (v5.2.0)
  - Removing fgrosse/phpasn1 (v2.2.0)
  - Removing defuse/php-encryption (v2.2.1)
  - Removing christian-riesen/base32 (1.3.2)
  - Removing brick/math (0.9.1)
  - Removing beberlei/assert (v3.3.0)
  - Upgrading wikimedia/composer-merge-plugin (v1.4.1 => dev-feature/composer-v2 a8c5a89): Checking out a8c5a89c60 from cache
Package phpunit/php-token-stream is abandoned, you should avoid using it. No replacement was suggested.
Generating optimized autoload files
36 packages you are using are looking for funding.
Use the `composer fund` command to find out more!
> ComposerVendorHtaccessCreator::onEvent
reedy@ubuntu64-web-esxi:/var/www/wiki/mediawiki/core$ php ../composer-2.0.phar update
> ComposerHookHandler::onPreUpdate
Loading composer repositories with package information
Updating dependencies                                 
Lock file operations: 24 installs, 0 updates, 0 removals
  - Locking beberlei/assert (v3.3.0)
  - Locking brick/math (0.9.1)
  - Locking christian-riesen/base32 (1.3.2)
  - Locking defuse/php-encryption (v2.2.1)
  - Locking fgrosse/phpasn1 (v2.2.0)
  - Locking firebase/php-jwt (v5.2.0)
  - Locking jakobo/hotp-php (v1.0.1)
  - Locking lcobucci/jwt (3.4.1)
  - Locking league/event (2.2.0)
  - Locking league/oauth2-server (dev-v9.0.0-alpha a00cc3c)
  - Locking league/uri (6.4.0)
  - Locking league/uri-components (2.2.1)
  - Locking league/uri-interfaces (2.2.0)
  - Locking psr/http-factory (1.0.1)
  - Locking ramsey/collection (1.1.1)
  - Locking ramsey/uuid (4.1.1)
  - Locking spomky-labs/base64url (v2.0.4)
  - Locking spomky-labs/cbor-php (v2.0.1)
  - Locking symfony/process (v5.2.0)
  - Locking web-auth/cose-lib (v3.2.10)
  - Locking web-auth/metadata-service (v3.2.10)
  - Locking web-auth/webauthn-lib (v3.2.10)
  - Locking wikimedia/css-sanitizer (v2.0.1)
  - Locking wikimedia/equivset (1.4.0)
Writing lock file
Installing dependencies from lock file (including require-dev)
Package operations: 24 installs, 0 updates, 0 removals
  - Syncing league/oauth2-server (dev-v9.0.0-alpha a00cc3c) into cache
  - Installing brick/math (0.9.1): Extracting archive
  - Installing christian-riesen/base32 (1.3.2): Extracting archive
  - Installing fgrosse/phpasn1 (v2.2.0): Extracting archive
  - Installing firebase/php-jwt (v5.2.0): Extracting archive
  - Installing jakobo/hotp-php (v1.0.1): Extracting archive
  - Installing league/event (2.2.0): Extracting archive
  - Installing lcobucci/jwt (3.4.1): Extracting archive
  - Installing defuse/php-encryption (v2.2.1): Extracting archive
  - Installing league/oauth2-server (dev-v9.0.0-alpha a00cc3c): Cloning a00cc3c274 from cache
  - Installing league/uri-interfaces (2.2.0): Extracting archive
  - Installing league/uri (6.4.0): Extracting archive
  - Installing league/uri-components (2.2.1): Extracting archive
  - Installing ramsey/collection (1.1.1): Extracting archive
  - Installing psr/http-factory (1.0.1): Extracting archive
  - Installing beberlei/assert (v3.3.0): Extracting archive
  - Installing web-auth/metadata-service (v3.2.10): Extracting archive
  - Installing web-auth/cose-lib (v3.2.10): Extracting archive
  - Installing symfony/process (v5.2.0): Extracting archive
  - Installing spomky-labs/cbor-php (v2.0.1): Extracting archive
  - Installing spomky-labs/base64url (v2.0.4): Extracting archive
  - Installing ramsey/uuid (4.1.1): Extracting archive
  - Installing web-auth/webauthn-lib (v3.2.10): Extracting archive
  - Installing wikimedia/css-sanitizer (v2.0.1): Extracting archive
  - Installing wikimedia/equivset (1.4.0): Extracting archive
12 package suggestions were added by new dependencies, use `composer suggest` to see details.
Package phpunit/php-token-stream is abandoned, you should avoid using it. No replacement was suggested.
Generating optimized autoload files
47 packages you are using are looking for funding.
Use the `composer fund` command to find out more!
> ComposerVendorHtaccessCreator::onEvent
reedy@ubuntu64-web-esxi:/var/www/wiki/mediawiki/core$

mcaskill commented 3 years ago

First run of composer update using composer 2.0 (specifically 2.0.8) and "dev-feature/composer-v2 as 1.5.0" results in all of the dependancies brought in via extra/merge-plugin/include (which are composer.json files themselves) originally by a composer 1.x version being removed and the merge plugin being updated.

Good point. I did not try updating dependencies from Composer 1.0 and then again in 2.0.

Thanks for spotting this.

Seldaek commented 3 years ago

So what happens is in the first update there the plugin is ignored so Composer is not aware of the merged dependencies and removes them, you see this with:

The "wikimedia/composer-merge-plugin" plugin was skipped because it requires a Plugin API version ("^1.0") that does not match your Composer installation ("2.0.0"). You may need to run composer update with the "--no-plugins" option.

I think the only way you might be able to fix this is if you update the plugin first using composer 1 to a version supporting both composer 1 and 2, then running with composer 2 should not delete the merged dependencies, as the plugin will be ready for composer 2 already.

Dmi3yy commented 3 years ago

Tested this PRs on Evolution CMS 3.0 All work correct

jimrome commented 3 years ago

I tried to test #189, but failed to get a working composer.json. Where exactly does this code go? I also tried using composer 1.x with "wikimedia/composer-merge-plugin": "dev-feature/composer-v2 as 1.5.0" as a requirement, and that failed also. Root composer.json requires wikimedia/composer-merge-plugin dev-feature/composer-v2 as 1.5.0, found wikimedia/composer-merge-plugin[dev-master, dev-composer20, v0.5.0, v1.0.0, ..., 1.5.x-dev (alias of dev-master)] but it does not match the constraint.

reedy commented 3 years ago

"require": { "wikimedia/composer-merge-plugin": "dev-feature/composer-v2 as 1.5.0", }, "repositories": [ { "type": "vcs", "url": "https://github.com/mcaskill/composer-merge-plugin" } ],

You basically need to bring the code above into your composer.json

Add the repository entry, update your require/require-dev entry

jedgar1mx commented 3 years ago

No issues using this version. 👍

amyh commented 3 years ago

I installed this using Composer 2.0.8 in the root composer.json of a Drupal 9 site, and it is working correctly.

jerrac commented 3 years ago

As far as installing dependencies listed in composer.libraries.json goes, it seems to work just fine with Drupal 8.9.11 and the webform module.

All I did was make the changes from the opening comment and then ran composer update --ignore-platform-reqs.

$ composer --version
Composer version 2.0.6 2020-11-07 11:21:17
$ php --version
PHP 7.3.25-1+ubuntu20.04.1+deb.sury.org+1 (cli) (built: Dec 26 2020 10:32:51) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.3.25, Copyright (c) 1998-2018 Zend Technologies
    with Zend OPcache v7.3.25-1+ubuntu20.04.1+deb.sury.org+1, Copyright (c) 1999-2018, by Zend Technologies

$ composer update --ignore-platform-reqs
Gathering patches for root package.
> DrupalProject\composer\ScriptHandler::checkComposerVersion
Loading composer repositories with package information
Updating dependencies
Lock file operations: 23 installs, 0 updates, 0 removals
  - Locking algolia/places (1.19.0)
  - Locking choices/choices (9.0.1)
  - Locking ckeditor/autogrow (4.14.1)
  - Locking ckeditor/codemirror (v1.17.12)
  - Locking ckeditor/fakeobjects (4.14.1)
  - Locking ckeditor/image (4.14.1)
  - Locking ckeditor/link (4.14.1)
  - Locking codemirror/codemirror (5.53.2)
  - Locking jquery/chosen (1.8.7)
  - Locking jquery/geocomplete (1.7.0)
  - Locking jquery/hotkeys (0.2.0)
  - Locking jquery/icheck (1.0.2 )
  - Locking jquery/image-picker (0.3.1)
  - Locking jquery/inputmask (5.0.5)
  - Locking jquery/intl-tel-input (16.1.0)
  - Locking jquery/rateit (1.1.3)
  - Locking jquery/select2 (4.0.13)
  - Locking jquery/textcounter (0.9.0)
  - Locking jquery/timepicker (1.13.14)
  - Locking jquery/toggles (4.0.0)
  - Locking progress-tracker/progress-tracker (1.4.0)
  - Locking signature_pad/signature_pad (2.3.0)
  - Locking svg-pan-zoom/svg-pan-zoom (3.6.1)
Writing lock file
Installing dependencies from lock file (including require-dev)
Package operations: 23 installs, 0 updates, 0 removals
  - Downloading codemirror/codemirror (5.53.2)
Gathering patches for root package.
Gathering patches for dependencies. This might take a minute.
  - Installing algolia/places (1.19.0): Extracting archive
  - Installing choices/choices (9.0.1): Extracting archive
  - Installing ckeditor/autogrow (4.14.1): Extracting archive
  - Installing ckeditor/codemirror (v1.17.12): Extracting archive
  - Installing ckeditor/fakeobjects (4.14.1): Extracting archive
  - Installing ckeditor/image (4.14.1): Extracting archive
  - Installing ckeditor/link (4.14.1): Extracting archive
  - Installing codemirror/codemirror (5.53.2): Extracting archive
  - Installing jquery/chosen (1.8.7): Extracting archive
  - Installing jquery/geocomplete (1.7.0): Extracting archive
  - Installing jquery/hotkeys (0.2.0): Extracting archive
  - Installing jquery/icheck (1.0.2 ): Extracting archive
  - Installing jquery/image-picker (0.3.1): Extracting archive
  - Installing jquery/inputmask (5.0.5): Extracting archive
  - Installing jquery/intl-tel-input (16.1.0): Extracting archive
  - Installing jquery/rateit (1.1.3): Extracting archive
  - Installing jquery/select2 (4.0.13): Extracting archive
  - Installing jquery/textcounter (0.9.0): Extracting archive
  - Installing jquery/timepicker (1.13.14): Extracting archive
  - Installing jquery/toggles (4.0.0): Extracting archive
  - Installing progress-tracker/progress-tracker (1.4.0): Extracting archive
  - Installing signature_pad/signature_pad (2.3.0): Extracting archive
  - Installing svg-pan-zoom/svg-pan-zoom (3.6.1): Extracting archive
Package container-interop/container-interop is abandoned, you should avoid using it. Use psr/container instead.
Package doctrine/reflection is abandoned, you should avoid using it. Use roave/better-reflection instead.
Package flow/jsonpath is abandoned, you should avoid using it. Use softcreatr/jsonpath instead.
Package phpunit/php-token-stream is abandoned, you should avoid using it. No replacement was suggested.
Generating autoload files
59 packages you are using are looking for funding.
Use the `composer fund` command to find out more!
> DrupalProject\composer\ScriptHandler::createRequiredFiles

b-sharpe commented 3 years ago

I'm having an issue with the post install run of update in my CI run. Because the CI is always installing it's artifact for the first time, it triggers isFirstInstall() and then post-install runs composer update again, which is unnecessary since my lock file already has all the merged dependencies. This can cause my lock file on my repo to not be the same as the lock that the CI's artifact builds and (luckily) fails my pipeline.

wikimedia / composer-merge-plugin

Add support for Composer v2 #189