Feature for composer 2.0 support

[boesing]

Q	A
BC Break	yes
New Feature	yes

Description

With this PR, I am introducing support for composer 2.0 aswell as a new behavior of this plugin (to stay in sync with composer 1.0.

I've added an ADR to the branch to provide some background on the decision to change the behavior of the plugin to a (hopefully) more future-proof way.

You can read this ADR in the next comment aswell as in the PR.

TODO

• Check if Travis build handles integration tests
• Add integration test for multiple non-migrated packages
• Add integration test for multiple non-migrated packages with shared dependencies
• Add integration test with an update to a migrated package from a non-migrated package
• Add uninstall handling of a package which was previously somehow required but not migrated
• Add integration test for uninstallation of a package which previously was not migrated
• Add update handling of a package which was previously not migrated but is migrated with the newest version
• Ask the user if we can remove the project requirement which was initially added by this plugin (in case it is not needed anymore)
• ...

[boesing]

Interactive mode over slipstreaming

Status

accepted

Context

With composer in v2.0, slipstreaming into the installation flow of composer does not work anymore. It is not possible to change the packages to be installed, why the initial method of this package does not work anymore.

Decision

We change the way how this package interacts with projects. The project lets install any package but gathers, which of these have to be replaced with laminas packages.

After composer finishes with dumping the autoloader, this plugin asks the user (in case there were packages installed which had to be replaced) if he wants to replace zendframework packages.

The default answer is "yes" (in case, composer install was called with --no-interaction).

If the answer is "yes", the following flow is executed:

1. Add laminas replacements to composer.json (with the locked version of the currently installed zend pendant)
2. Update composer.lock (which uninstalls zend and installs laminas packages)
3. Add laminas replacements to composer.json (with previous constraint of that package which required the zendframework package)
4. Update composer.lock (with composer update --lock) to synchronize composer.lock with composer.json

Consequences

The user now has to interact with this plugin. We are not auto-replacing zend-packgages anymore.
This takes some more i/o as we have to write the composer.json and composer.lock multiple times.

This only happens once for the project OR if you add a non-migrated 3rd-party library, which contains not already replaced zend packages.

If the dependency is added to composer.json, there is no guarantee if the user will need the package replacement for upcoming releases of the 3rd party library. This is why we need to keep track on why a laminas replacement was added to the composer.json.

[boesing]

Removing unit-testing dev-dependencies

Status

proposed

Context

With composer in v2.0, a removal of packages without existing composer.lock is not allowed.

Cannot update only a partial set of packages without a lock file present.

Decision

We remove the dev-dependencies for unit-testing by default and require them in travis builds.

Consequences

Every contributor has to manually add the dependencies if he wants to execute unit tests.

[boesing]

I'd like to get feedback about the proposal to remove dev-dependencies regarding unit testing.
With composer 2.0, the current flow in most of the packages wont work anymore. So either, we are removing packages with bash-tools and keep em in composer.json or we find another solution for this...

As I am busy with the further development of integration tests and some features I'd love if someone else can find a way. Until then, I keep the code as is.

[boesing]

Closing in favor of #18