Slip stream in composer 2.0

[boesing]

Q	A
New Feature	yes

Description

While trying to migrate to composer 2.0, I've tried many ways on how to achieve the functionality of the current plugin.

The current plugin "slip streams" into the composer process, which is probably the best solution to solve the following scenarios:

• If 3rd-party library has a zend-dependency and updates to laminas, there wont be any changes to the project as the laminas package is already required.

• If a 3rd-party library has a zend-dependency and requires a newer zend-dependency, the project will just upgrade to the laminas equivalent. No further action needed.

• If a 3rd-party library totally drops a zend-dependency and does not need the laminas equivalent, the slip-streamed laminas dependency will automatically being removed from the project if its not needed anymore.

I came up with a way in #15 which should have introduced some more user interactions. The main idea was:

If a 3rd-party library has a zend-dependency, ask the user if he wants to replace that zend-dependency the laminas pendant, write the dependency to composer.json of the project and remember that we introduced that dependency due to a non-migrated library.

TL;DR

This is finally ready for review.

Story on why I decided to go this way

After many sleepless nights and a total rewrite of the dependency plugin, I realized that this approach would probably be a future proof solution but its way too complex.
The complexity exceeded my brain capacity too often.
Its unmaintainable due to all those possible combinations:

• 3rd-party library no.1 uses zend-dependency and is required via root composer.json as a require package
• 3rd party library no.2 uses same zend-dependency and is required via root composer.json as a require-dev package
• 3rd party library no.1 is being uninstalled
• root composer.json should change the require of the laminas equivalent to require-dev as there is only a dev-requirement left which requires the zend-package

And thats just one of those complex scenarios...

However, after I realized that #15 wont be a solution I am happy with, I started to work on this approach today. I don't know why I tried this earlier (as I was debugging what exactly changed in composer 2.0 that the slip-stream solution we are actually use does not work anymore)... That would probably saved my a ton of work.

[boesing]

Well, now travis fails because codestandard says "closure can be static" but it can't as it wont set the property anymore... Thats why I hate changing code I didn't wrote myself... 👎

[samsonasik]

I didn't write "static" in my example #18 (comment) , you added static yourself, that's why it got error.

[boesing]

I didn't write "static" in my example #18 (comment) , you added static yourself, that's why it got error.

I've applied phpcbf which changed it to static without me noticing.
After tests failed, I dropped static and now phpcs is arguing about missing static.

Welcome to QA hell.

[boesing]

@weierophinney Any ideas how to raise code coverage? it needs to get merged from both results of COMPOSER_VERSION v1 and v2...

[weierophinney]

After tests failed, I dropped static and now phpcs is arguing about missing static.

Welcome to QA hell.

Wrap the closure (or at least its opening line) with // phpcs:disable and // phpcs:enable, if tests fail when it is marked as static.

[weierophinney]

Any ideas how to raise code coverage? it needs to get merged from both results of COMPOSER_VERSION v1 and v2...

No clues whatsoever... maybe @michalbundyra might have ideas?

[codecov-commenter]

Codecov Report

❗ No coverage uploaded for pull request base (develop@781d6f7). Click here to learn what that means.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             develop      #18   +/-   ##
==========================================
  Coverage           ?   92.33%           
  Complexity         ?       97           
==========================================
  Files              ?        5           
  Lines              ?      339           
  Branches           ?        0           
==========================================
  Hits               ?      313           
  Misses             ?       26           
  Partials           ?        0           

Flag	Coverage Δ	Complexity Δ
#composer1	52.80% <0.00%> (?)	97.00% <0.00%> (?%)
#composer2	69.32% <0.00%> (?)	97.00% <0.00%> (?%)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 781d6f7...2e12ce2. Read the comment docs.

[boesing]

Well, I finally got proper codecoverage.
Its around 92% now.

Hopefully, thats enough. I also removed dev-dependency of composer/semver and thus, I think we're ready for a release candidate.

[weierophinney]

This looks fantastic - surprised to see you found a way to keep the current functionality with the v2 API - I'm assuming the "POOL" events must be the secret to making that work?

I have no feedback at a technical level. I haven't had time to dive into where and when the POOL events are triggered, but I trust you did the research!

Let's do an alpha or beta release from this, and have people start testing!

[weierophinney]

We should probably move to Laminas Coding Standard v2, but that can wait for another PR. 😄

[boesing]

I'm assuming the "POOL" events must be the secret to making that work?

Yah, more or less. Jordi pointed me to this event, but it is being triggered before any package is being downloaded. As I've started to implement the initial version, I realized, that the dependency-plugin was not able to interact due to the fact, that it was not downloaded at the point when the events are triggered (in a project which is being installed for the first time - so without the vendor/ directory available).

That was what made me thinking about the way we discussed a few months ago. That other way drove me crazy after a few weeks of developing and thus I tried this approach again.
However, I am happy that this works, even if I dont like the fact that we have to re-run composer again to ensure we have our packages slip-streamed.

Flow is as follows (for a freshly installed package):

• Pool event is being triggered
• Packages are being downloaded to vendor/
• Packages are being triggered (install or update event)
• Plugin detects zend packages
• Composer executes dump-autoloader
• Plugin hooks into that and executes uninstall for all zend packages
• Plugin executes composer update --lock
• Pool event is being triggered
• Plugin changes zend packages to laminas packages in the pool
• composer.lock is being written with the laminas replacements
• Composer installs laminas package in favor of zend package
• dump-autoload is being triggered again (this time we dont care as we did our job)

So hopefully, we have the same features as in the first version of this plugin.

@weierophinney I would love to see this as a first preview release so contributors can start testing with the new version.

[weierophinney]

@boesing Go ahead and merge to develop, and issue a 2.0.0beta1 release. I'm suggesting beta, in case we determine there might be additional features before we do a stable release; that way we can do another beta. Otherwise, we can jump directly from beta to stable if user tests show it working as expected.

[roelvanduijnhoven]

Just want to give feedback: works great for me with the composer 2.0 plugin :). Just pushed our app to production, using this beta.

[snapshotpl]

~2.0.0@dev can be removed after stable 2.0

[snapshotpl]

Can be null

[snapshotpl]

Can be null