Skip to content

[2.1.0] module:uninstall can remove code it uses itself #5797

Closed
@hostep

Description

@hostep

Preconditions

  1. Figure out a way to travel back and forth in time (I added some hints)
  2. We use composer version 1.1.3 by adding this to our composer.json file: "composer/composer": "1.1.3 as 1.0.0-beta1",, due to another bug, but I think it won't really matter which version is being used
  3. PHP 7.0.9
  4. Magento 2.1.0

Steps to reproduce

  1. Travel back in time to when symfony/process version 2.8.8 wasn't released yet (hint: try to downgrade to version 2.8.7 of the module after step 2)
  2. Install Magento 2.1.0 using composer
  3. Install a third party module using composer (composer require, bin/magento setup:upgrade, ...)
  4. Travel back to the current time when symfony/process version 2.8.8 was released (hint: don't do anything in this step)
  5. Uninstall the module you installed in step 3 by using bin/magento module:uninstall

Expected result

  1. Module is uninstalled without a problem

Actual result

  1. When Magento tries to uninstall the module using composer, it also at the same time tries to update symfony/process from version 2.8.7 to 2.8.8 for some strange reason. And since symfony/process is being used by the module:uninstall command, the command stops running.
  2. Console output:
➜ php bin/magento module:uninstall Vendor_MyModule
You are about to remove code and/or database tables. Are you sure?[y/N]y
Enabling maintenance mode
You are about to remove a module(s) that might have database data. Do you want to remove the data from database?[y/N]N
Removing Vendor_MyModule from module registry in database
Removing Vendor_MyModule from module list in deployment configuration
Removing code from Magento codebase:
Command "remove" failed: Loading composer repositories with package information
Updating dependencies (including require-dev)
  - Removing vendor/my-module (v1.0.11)
Removing Vendor/MyModule
  - Removing symfony/process (v2.8.7)

Removal failed, reverting ./composer.json to its original content.



  [ErrorException]
  include(/Users/me/Projects/my-project/vendor/composer/../symfony/process/ExecutableFinder.php): failed to open stream: No such file or directory



remove [--dev] [--no-progress] [--no-update] [--update-no-dev] [--update-with-dependencies] [--no-update-with-dependencies] [--ignore-platform-reqs] [-o|--optimize-autoloader] [-a|--classmap-authoritative] [packages1] ... [packagesN]



Please disable maintenance mode after you resolved above issues

Bit of debugging

It turns out at the step when the composer remove step is executed, this happens:

➜ composer remove --working-dir=/Users/me/Projects/my-project vendor/my-module
Loading composer repositories with package information
Updating dependencies (including require-dev)
  - Removing vendor/my-module (v1.0.11)
Removing Vendor/MyModule
  - Removing symfony/process (v2.8.7)
  - Installing symfony/process (v2.8.8)
    Loading from cache

Package fabpot/php-cs-fixer is abandoned, you should avoid using it. Use friendsofphp/php-cs-fixer instead.
Writing lock file
Generating optimized autoload files

So for some reason symfony/process gets updated to the latest version while removing another module which has no direct dependencies on symfony/process. But this particular module has some dependencies on some magento modules which in itself will probably have dependencies on symfony/process module.

I think you can work around this if you add the --no-update-with-dependencies switch, since that won't update symfony/process:

➜ composer remove --no-update-with-dependencies --working-dir=/Users/me/Projects/my-project vendor/my-module
Loading composer repositories with package information
Updating dependencies (including require-dev)
  - Removing vendor/my-module (v1.0.11)
Removing Vendor/MyModule
Package fabpot/php-cs-fixer is abandoned, you should avoid using it. Use friendsofphp/php-cs-fixer instead.
Writing lock file
Generating optimized autoload files

Please review thoroughly, because this seems to be something which can turn out to be quite complicated!
Also: I haven't tested my solution with that --no-update-with-dependencies flag yet.

For other people running into this problem: first update all your dependencies to the latest version by just running composer update (hint you can run composer update --dry-run to preview what it will do first) and only after your dependencies are updated, run the module:uninstall command.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Component: SetupFixed in 2.2.xThe issue has been fixed in 2.2 release lineFixed in 2.3.xThe issue has been fixed in 2.3 release lineIssue: Format is validGate 1 Passed. Automatic verification of issue format passedIssue: Ready for WorkGate 4. Acknowledged. Issue is added to backlog and ready for developmentReproduced on 2.1.xThe issue has been reproduced on latest 2.1 releasebug report

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions