Updating Module

This section describes the process of updating a module.

Problem

It will be a rare scenario for developers to use other peoples' modules 'as is'. Most likely, they will have to do some customizations, extensions, improvements. Moreover, after some time, a new version of such a customized module could be pushed. Upgrading the module most likely will create conflicts between files updated via the module's creator and customizations made by the developer. We need to provide a decent UX and workflow for resolving those conflicts.

Current behavior

Currently, you can use the pos-cli modules * helper command to pull public files. When you are done and you deploy changes, the original module files are overwritten. It means, that upgrading the module would overwrite your overwrites.

Solution

The pos-cli deploy command should not overwrite the original module files. Instead, it should create/update duplicates. Upgrading the module should overwrite the original module files, not the duplicates. Thanks to this, after upgrading the module, you will still have all your customizations and you will be able to update your overwrites to match the newest version. Sometimes, upgrading the module might not need any action from the user. We should make sure that overwrites have precedence over original files, for example if a partial, a page, or a form configuration exists as an original file and an overwrite, we should always use the overwrite first.