— Feature Card
Description
Right now, as soon as a developer installs a package as a local package, it loses the ability to update that package. We can add an update-package command to solve that.
User stories
As a Frontity developer
I want to update a local package
so that I can merge the latest changes with my own.
Possible solution
We can check for git first, then check if everything is committed and finally do the update. That way users can review the changes and do a proper merge. It could also ask the user for the name of a new branch.
I have created a small video explaining a possible workflow of npx frontity update-package.
(sorry for the rough ending, but Loom crashed 
)
I think this is probably worth exploring a little more, because the VS Code workflow I have used in the video (select lines, right-click, revert changes) is not the most intuitive one. I’m sure we can come up with a better recommendation to merge the changes.
But apart from that, in my opinion, there are a couple of benefits of this approach vs a child-theme approach:
- In a child theme changes are not merged. Instead, the whole file is just replaced. That makes more difficult to keep up to date with the upstream changes.
- In a child theme the file structure cannot be changed. This is probably not ideal in git either, but at least it is possible.
I’m not against child-themes (or child-packages). I think they are fine and we should probably support both approaches.
Great video Luis! Thanks for the explanation 
I agree that, at least as an starting point, this is a good approach.
Just to know and consider it, would it be possible to create a list of files inside my Frontity project and just check the changes in those files? If I’m not mistaken in WordPress child themes if you create a file (header.php for example), it overwrites the parent’s file. So if you update your parent theme, all the files are updated, but the header.php file would be overwritten by the child theme.
If, somehow, users are able to list the files that they change in each package, the workflow could be similar.
Uhmm… ok so you mean that when you update, the command gives you two lists:
- Files that you never changed, but are now changed because of the update.
- Files that you changed and are now changed because of the update.
I think it’s going to be really difficult to come up with such a list because:
- It will be nearly impossible to distinguish between changes that are a revert of your changes and changes that are an update.
- You should take a look at all the changes because they may affect your app. Even changes in files you never changed, like for example a change in the prop name of a component or the argument order of a function.
