Skip to content

Latest commit

 

History

History
29 lines (26 loc) · 4.43 KB

process_flows.md

File metadata and controls

29 lines (26 loc) · 4.43 KB
Raw

Plugin operation flow explanations and diagrams

composer require-commerce <metapackage>

Scenario: The user has an installed Magento Open Source or Adobe Commerce project and wants to upgrade to a new version. They call composer require-commerce <metapackage> from the command line

  1. Composer boilerplate and plugin setup
    1. Composer sees the "type": "composer-plugin" value in the composer.json file for the plugin package
    2. Composer reads the "extra"->"class" field to find the class that implements PluginInterface (PluginDefinition)
    3. PluginDefinition implements Capable, telling Composer that it provides some capability (CommandProvider), which is supplied through PluginDefinition::getCapabilities()
    4. CommandProvider::getCommands() supplies Composer with an instance of RequireCommerceCommand
    5. Composer calls RequireCommerceCommand::configure() to obtain the command's name, description, options, and help text
      • RequireCommerceCommand extends Composer's native RequireCommand and adds its own values to those in the existing implementation
    6. Composer adds RequireCommerceCommand to the registry
  2. Composer recognizes require-commerce as the command passed to the executable and finds RequireCommerceCommand as the command object registered under that name
  3. Composer calls RequireCommerceCommand::execute()
  4. RequireCommerceCommand::execute() backs up the user's composer.json file through ExtendableRequireCommand::parseComposerJsonFile()
  5. RequireCommerceCommand::execute() calls RequireCommerceCommand::runUpdate()
  6. RequireCommerceCommand::runUpdate() calls RequireCommerceCommand::parseMetapackageRequirement() to check the composer require-commerce arguments for a magento/product or magento/magento-cloud metapackage
  7. If a magento/product or magento/magento-cloud metapackage is found in the command arguments, it calls RootProjectUpdater::runUpdate()
  8. RootProjectUpdater::runUpdate() calls DeltaResolver::resolveRootDeltas()
  9. DeltaResolver::resolveRootDeltas() uses RootPackageRetriever to obtain the Composer Package objects for the root composer.json files from the default installation of the existing edition and version, the target edition and version supplied to the composer require-commerce call, and the user's current installation including any customizations they have made
  10. DeltaResolver::resolveRootDeltas() iterates over the fields in composer.json to determine any values that need to be updated to match the root project's composer.json file of the new Magento Open Source or Adobe Commerce edition/version
  11. To find these values, it compares the values for each field in the default project for the installed edition/version with the project for the target edition/version (DeltaResolver::findResolution())
  12. If a value has changed in the target, it checks that field in the user's customized root composer.json file to see if it has been overwritten with a custom value
  13. If the user customized the value, the conflict will be resolved according to the specified resolution strategy: use the expected project's value, use the user's custom value, or prompt the user to specify which value should be used
  14. If resolveRootDeltas() found values that need to change, RequireCommerceCommand::runUpdate() calls RootProjectUpdater::writeUpdatedComposerJson() to apply those changes
  15. RequireCommerceCommand::execute() calls the native RequireCommand::execute() function, which will now use the updated root composer.json file if the plugin made changes
  16. If the RequireCommand::execute() call fails after the plugin makes changes, RequireCommerceCommand::execute() calls ExtendableRequireCommand::revertRootComposerFile() to restore the composer.json file to its original state