Use modern \Composer\InstalledVersions instead of \PackageVersions\Versions

[MikeyBeLike]

My IDE is complaing that \PackageVersions\Versions is deprecated and to use the native \Composer\InstalledVersions instead

This wasn't working in one of my CI environments and I can only assume it was down to composer 2

[scrutinizer-notifier]

A new inspection was created.

[tabacitu]

Ugh - seems like this one slipped through the cracks @MikeyBeLike - sorry for that.

It's odd you've gotten this, thanks for the heads-up. I do agree we should do this, but unfortunately it sounds like a breaking change, so we can only do it at the next minor version bump (4.2, right around the corner).

I'm saying that because:

• not everybody has upgraded to Composer 2 yet, so not everybody has Composer\InstalledVersions yet;
• one of the places where we use it is inside the config/backpack/base.php config file, which... once published, is out of our hands; so yes we'd change it in the package config file, but because it's published, people won't get the update (unless we have a minor version bump with an upgrade guide - then we can tell them to make the change too);

This will be a tricky one - I don't know how fast enough people will have upgraded to Composer 2, so we can call Composer 1 "dead"...

[tabacitu]

Update: At the moment it looks like only 65% of all PHP developers are using the new version of composer, so I’m afraid we’re going to have to postpone this until the next version…

[stof]

This PR is missing 2 things:

• removing the dependency on composer/package-versions-deprecated as it is not used anymore
• adding a dependency on composer-runtime-api ^2 to be able to use the runtime API safely i.e. dependency resolution will fail (or use an older version of that package) if using composer 1 which does not have that runtime API

[tabacitu]

Huh, thank you @stof - didn't know we can use composer-runtime-api... I thought https://github.com/Jean85/pretty-package-versions is the one to go with, but we'll investigate that too, thanks 🙏

[stof]

Using composer-runtime-api is exactly what this PR is doing when using the Composer\InstalledVersions class, but without declaring the dependency (and so without ensuring that the composer runtime API is at a version supporting Composer\InstalledVersions)

[tabacitu]

Got it, thanks.

Note to self. I've investigated this a little bit:

• like @stof said, composer-runtime-api needs to be required in this PR, to make it work safely using Composer v2; BUT even with that change, this PR will make Backpack uninstallable with Composer v1;
• we can use a third-party package like https://github.com/Jean85/pretty-package-versions to support both Composer v1 and Composer v2, with one syntax;

At the moment 75% of all devs use Composer v2. Which means there's been a 10% improvement in less than 2 months. So I think the choice is between:

• (A) forcing people to use Composer v2 in Backpack v4.2;
• (B) adding the jean85 dependency this month (when launching v4.2) to support both Composer v1 and Composer v2; then removing it in Backpack v5 (when hopefully the % will be over 80-90%);
• (B) doing nothing; waiting 6 more months until we launch v5 to merge this PR, and skip adding and removing the jean85 dependency altogether;

I guess:

• the easiest for us maintainers would be to do Option A, and force people to upgrade Composer;
• the easiest for devs would be Option C, since there's nothing for them to do (and for now the package is just deprecated);

So in the end, it's all tied into the decision of "How many dependencies do we force people to upgrade, to use Backpack v4.2?":

• do we force them to use Laravel 9? and in consequence PHP 8.x? if so, forcing them to use Composer v2 is in the same spirit;
• do we allow people to use Laravel 8? and in consequence PHP 7.3, 7.4 and 8.x? if so, forcing them to use Composer v2 doesn't really make sense;

I'll sleep on it and make a decision. Thanks for the help here, everyone!

[tabacitu]

I've decided we shouldn't do this now. Let's revisit in about 6 months when we launch v5. Until then... it's just a notice, we can ignore it.

[pxpm]

We missed revising this when launching v5, so let's make sure we don't miss it again in the next major 😄

Also, as added in https://github.com/Laravel-Backpack/CRUD/issues/4725 it could be a good improvemente to add "composer-runtime-api": "^2.0" in composer.json.

[scrutinizer-notifier]

The inspection completed: 1 new issues

[tabacitu]

Good news! This is now fixed in v6 thanks to https://github.com/Laravel-Backpack/CRUD/commit/2017935202e7281d96b9709224b34fe7ab429c0f and https://github.com/Laravel-Backpack/CRUD/pull/5052

Thanks for the PR @MikeyBeLike - it'll show up as Closed not Merged but we super-appreciate you submitting this 🙏

Cheers!