Composer package manager became a standard when it comes to modules, themes, language packages for Magento 2 platform. It is a good way to keep all dependencies up to date with 3rd party libraries which provides utilities for the package. Even though, custom Magento 2 module extends existing Magento 2 modules which come out-of-box the importance of including all Magento 2 modules can’t be underestimated.
In most cases, extension developers spend minimum time and effort to check and update the composer.json file. The effect of the outdated dependencies can be dramatic for production Magento 2 environments. It simply can break in the middle of the critical customer journey towards making an online purchase.
Example
For example, Magento 2 custom module provides payment integration with payment service provider and enables new payment method on the checkout payments page. The module extends seven Magento 2 modules including Sales, Payment, Checkout, UI, Backend, Quote, Customer. Also, the module relies on classes and interfaces from the Magento Framework.
The module’s dependencies in the composer.json file looks the following:
"require": {
"php": "~5.5.22|~5.6.0|7.0.2|7.0.4|~7.0.6",
"magento/framework": "*"
}
Every time you update your Magento 2 installation there is a big risk to break the installation in case a module has undeclared dependencies in the composer.json file. Simply, because composer package manager doesn’t check compatibility with other modules than the “magento/framework” version with asterisk. As a result, the “composer update” command will successfully finish all updates without a backward incompatible package notice.
Moreover, custom Magento 2 module can support some of Magento 2 modules versions due to its different set of APIs introduced in different Magento 2 modules.
Solution
It is a good practice to explicitly provide package versions in the Magento 2 module composer.json file. Instead of relying on the successful composer completion, let the composer check compatibility of your packages before the updates will go to the production environment.
The ideal set of dependencies should include the following:
- Dependency on the Magento 2 module if the module extends/change/remove the functionality.
- Different versions of the Magento 2 module to highlight the compatibility with Magento 2.0.x, 2.1.x, 2.2.x etc versions.
- External packages and its versions
- Magento Framework dependency
Here is the example of the composer.json file with the dependencies from the Magento 2 Realex Payments module:
"require": {
"magento/module-store": "100.1.*|100.2.*",
"magento/module-config": "100.1.*|100.2.*",
"magento/module-payment": "100.1.*|100.2.*",
"magento/module-vault": "100.2.*|100.3.*",
"magento/module-sales": "100.1.*|100.2.*",
"magento/module-checkout": "100.1.*|100.2.*",
"magento/module-quote": "100.1.*|100.2.*",
"magento/module-backend": "100.1.*|100.2.*",
"magento/module-customer": "100.1.*|100.2.*",
"magento/module-reports": "100.1.*|100.2.*",
"magento/module-ui": "100.1.*|100.2.*",
"magento/framework": "100.1.*|100.2.*",
"psr/log": "1.0.*"
}
The example shows that the module is compatible with modules released as part of both Magento 2.1.x and Magento 2.2.x versions.
Further Reading
I recommend to read the following articles to get a better idea of semantic versioning:
- Magento 2 Version Numbering Update
- Magento 2: Composer for Extensions Distribution
- Magento 2 Extension Dev Guide: Versioning
Merry Christmas,
Max Pronko