Create a task to update existing extensions

[aldesantis]

Problem

Currently, extensions can be updated by re-running the generator in the extension's directory with solidus extension ., but this is not very handy because it generates a bunch of conflicts which are bound to get worse and worse as the extension grows.

This is not a problem if the task must only be run once when adopting solidus_dev_support in an existing extension, but it will become time-consuming as new versions of solidus_dev_support are released and extension maintainers want to update their extensions to match the new conventions.

Proposed solution

A better experience would be to provide a solidus extension update task that looks at the current version of solidus_dev_support, computes the differences with the latest and only applies the necessary changes. For instance, if the latest version of solidus_dev_support updates solidus_support from 0.4.0 to 0.5.0, then running solidus extension update would only make that specific change in the gemspec by finding/replacing the right line.

Technical approach

I'm not sure how we could approach this, but I imagine we'll have to design some kind of migration system similar to what ActiveRecord has, except it will be for directories and files rather than for tables and columns.

[kennyadsl]

Just wanted to chime in by saying one thing that I don't like about the solidus extension . command to update extensions: it keeps trying to inject things into extensions every time, even if for some reason I already decided to keep something in the way it is.

For example:

• solidus extension . asks me to add Rubocop linting to my extension.
• I check the extension with a long and boring analysis and decide that I can't use Rubocop at the current state
• I remove the code proposed by the update task
• After one week someone else tries to update with solidus extension .
• They don't know that I already decided, for some reason, to keep Rubocop off.
• They waste their time again to understand what to do (and probably come up with a different decision, which is not bad but I guess it's better to focus firepower on something else).

I can't think of a real solution on this, other than keep spending time to make sure that all extensions are actually able to do what proposed by the update task and keep moving things into SolidusSupport and SolidusDevSupport. For example, we could extract Engine, Version, Configuration, Install Generator and probably many other classes into an abstract class in SolidusSupport that other extensions use so that there will be less boilerplate code and we can change things is a single place to have them applied to all extensions.

[chrean]

I think our time would be better spent on other things, especially now that we are redoing most critical extensions.