Define dependency of Magento_CatalogUrlRewrite to Magento_ImportExport as soft dependency

[avstudnitz]

Description (*)

When trying to remove all *ImportExport modules, the only unexpected dependencies were those from the Magento_CatalogUrlRewrite to Magento_CatalogImportExport and Magento_ImportExport:

{
    "name": "magento/module-catalog-url-rewrite",
    "description": "N/A",
    "config": {
        "sort-packages": true
    },
    "require": {
        "php": "~7.1.3||~7.2.0",
        "magento/framework": "*",
        "magento/module-backend": "*",
        "magento/module-catalog": "*",
        "magento/module-catalog-import-export": "*",
        "magento/module-eav": "*",
        "magento/module-import-export": "*",
        "magento/module-store": "*",
        "magento/module-ui": "*",
        "magento/module-url-rewrite": "*"
    },
    [...]
}

The Magento_CatalogUrlRewrite module contains two observers (\Magento\CatalogUrlRewrite\Observer\AfterImportDataObserver, \Magento\CatalogUrlRewrite\Observer\ClearProductUrlsObserver) which observe events from the Magento_CatalogImportExport module (catalog_product_import_bunch_save_after, catalog_product_import_bunch_delete_after) and contain references to ImportExport modules (constants and return types only, no classes instantiated via DI).
If Magento_CatalogImportExport is disabled or removed, these two observers aren't instantiated or used otherwise. This means, Magento_CatalogUrlRewrite will work perfectly if the ImportExport modules are not available. In my opinion it's a soft dependency ("A module with a soft dependency on another module can function properly without the other module, even if they have a dependency upon it.", see https://devdocs.magento.com/guides/v2.3/architecture/archi_perspectives/components/modules/mod_depend_types.html). Thus, I suggest to not require the classes in question but just suggest them so we can use Magento_CatalogUrlRewrite without Magento_CatalogImportExport and Magento_ImportExport.

Manual testing scenarios (*)

1. Remove the ImportExport modules, i.e. by adding the following section to your composer.json:

    "replace": {
        "magento/module-advanced-pricing-import-export": "*",
        "magento/module-bundle-import-export": "*",
        "magento/module-catalog-import-export": "*",
        "magento/module-configurable-import-export": "*",
        "magento/module-customer-import-export": "*",
        "magento/module-downloadable-import-export": "*",
        "magento/module-grouped-import-export": "*",
        "magento/module-import-export": "*",
        "magento/module-tax-import-export": "*"
    },

2. Check that the CatalogUrlWrite still works by creating a product in the Magento Admin and checking that it is available in the frontend with a "speaking" URL. Do the same with a category.

Contribution checklist (*)

• Pull request has a meaningful description of its purpose
• All commits are accompanied by meaningful commit messages
• All new or changed code is covered with unit/integration tests (if applicable)
• All automated tests passed successfully (all builds on Travis CI are green)

[magento-engcom-team]

Hi @avstudnitz. Thank you for your contribution
Here is some useful tips how you can test your changes using Magento test environment.
Add the comment under your pull request to deploy test or vanilla Magento instance:

• @magento-engcom-team give me test instance - deploy test instance based on PR changes
• @magento-engcom-team give me 2.3-develop instance - deploy vanilla Magento instance

For more details, please, review the Magento Contributor Assistant documentation

[avstudnitz]

I see there is a test failing which checks for dependency declarations.
Should we have a new module Magento_CatalogImportExportUrlRewrite which has dependencies to magento/module-catalog-url-rewrite, magento/module-catalog-import-export and magento/module-import-export and contains the two observers instead? I think that would be the clearest way to do it if the above suggested way to just undeclare the hard dependencies doesn't work out.

[miguelbalparda]

@kandy can you please comment on what @avstudnitz proposed? Thanks!

[kandy]

@avstudnitz, @miguelbalparda Yep, It's common recommendation to move hard dependencies in separate module (see MSI, GraphQL modules as example)

[miguelbalparda]

@avstudnitz would you rather keep working on this PR or create a new one for the changes @kandy proposed?

[avstudnitz]

Let's keep working on this. It might take a few weeks until I get to work on this again.

[sidolov]

Hi @avstudnitz , will you continue progress on the PR?

[avstudnitz]

Sorry, I don't have time at the moment. You can close it for now.

[sidolov]

@avstudnitz , I am closing this PR now due to inactivity.
Please reopen and update if you wish to continue.
Thank you for the collaboration!

[m2-assistant]

Hi @avstudnitz, thank you for your contribution!
Please, complete Contribution Survey, it will take less than a minute.
Your feedback will help us to improve contribution process.