Remove wikimedia/composer-merge-plugin

+++ b/composer.lock
@@ -693,7 +693,10 @@
+            "description": "Drupal is an open source content management platform powering millions of websites and applications.",
+            "transport-options": {
+                "relative": true
+            }
         },

@@ -723,7 +726,10 @@
+            ],
+            "transport-options": {
+                "relative": true
+            }

@@ -753,7 +759,10 @@
-            ]
+            ],
+            "transport-options": {
...
+            }

@@ -6544,5 +6504,6 @@
-    "platform-dev": []
+    "platform-dev": [],
+    "plugin-api-version": "1.1.0"

Looks like they are unexpected changes, submitting the new one generated while reviewing.

Bumping priority since this blocks a critical issue.

Remaining direct deprecation notices (2)

2x: Passing an escaped locator to the named selector is deprecated as of 1.7 and will be removed in 2.0. Pass the raw value instead.
2x in DisplayTest::testDisplayPlugin from Drupal\Tests\views\Functional\Plugin

Seems irrelevant

Nice catch! I bet the branch is valid

This will need to be backported to 9.0.x during the beta I think.

The deprecated message in #8 or #11 is from \Behat\Mink\Selector\NamedSelector::escapeLocator()

 @trigger_error(
                'Passing an escaped locator to the named selector is deprecated as of 1.7 and will be removed in 2.0.'
                .' Pass the raw value instead.',
                E_USER_DEPRECATED
            );

This xpath in \Drupal\Tests\views\Functional\Plugin\DisplayTest::testDisplayPlugin() may be the culprit

$result = $this->xpath('//ul[@id="views-display-menu-tabs"]/li/a/child::text()');

I think this should be fixed in a separate issue.

The error in #8 looks like a random fail from upstream: https://www.drupal.org/project/drupal/issues/3041318

Do a quick test to prove that it's a random fail from upstream with tailored CI.

As #17 is green. proved it was!

Generally +1. Because we're changing the expectations on the users, we need a CR saying that you'll need to specify the merge plugin after 9.0.0 (or whenever this gets released).

There's still not a patch to review.

Also is there a separate issue for the random fail so we can isolate that out?

1. CR added by @greg.1.anderson https://www.drupal.org/node/3127178
2. #8 is the patch to be reviewed.
3. #3041318 reported the random fail. It's out of scope to fix it here

So set back to Needs Review.

Checked patch from #8 for me it looks good, applies without issues, composer install ran successfully, the local website also looks good.

Saving credit.

Committed/pushed to 9.1.x then backported to 9.0.x, thanks!

Good point we should at least discuss it.

A patch for 8.9.x

I think the only reason we left it lying around is on the off chance that people had custom modules and were relying on it shipping with core. Its really nbd if it gets removed, as people can always add it back with a composer command, but it hints at that whole "what do we actually consider an api change here"

The original change record here: gives end users instructions on what to do in that situation.
https://www.drupal.org/node/3069730

Im thinking we could probably remove it in 8.9.x as well.

BTW. the patch in #33 for 8.9.x does not apply to 8.8.x, Probably, it's just because, #3078671: Pin behat/mink and behat/mink-selenium2-driver to use resolvable release has not been ported to 8.8.x.

Yeah I think we should focus on 8.9.x support here since that's the release that'll be supported until the end of next year, and if there is any disruption, we wouldn't want that in a patch release.

#36 ah true. So basically its just lying around in the git clone. I think we can safely remove it without any forseeable disruption.

Patch is identical to #8 except for the lock hash, so this is good to go in 8.9.x.

OK I think it's more important to have 8.9 compatibility with composer 2 than the theoretical disruption via removing the merge plugin from composer.lock.

Committed fa275bd and pushed to 8.9.x. Thanks!

Updated the release note to justify why we're removing a dependency in a minor release and to provide an actionable next step for anyone affected. (What it was before; what it is now; who's affected; what they should do.)

I'm updating the GitHub link to reflect the most recent progress on this issue.

Should the Change Record status be updated to "Published"? It is now in "Draft".

Also, I see a lot of Change Records where the parent issue is fixed, but the Change Record is still in "Draft".

@ressa, yes, but before publishing the change record it needs to be reviewed. One can't expect that it is accurate and up to date.

In this case, I have updated the CR and published it.

@quietone: I agree 100%, a change record needs to be reviewed before publishing.

But since the change was rolled out more than three years ago, it's high time the Change record was published.

And thanks for going through the big back log of Change records (~100?) and publishing the forgotten ones.