Magento 1: improving my module development workflow (Modman, composer, git)

Question

This is something I've had in mind for quite some time but I can't find the right method to do it.

So basically, I'm working with 6 different websites, all running Magento CE 1.9.2+

On those websites, I am using a bunch of extensions that me and the team I'm working with have developped (here we're talking 50+ extensions) and the code for those extensions is stored on Bitbucket. So I ain't the only person managing those extensions, we're 3 people working on them.

At the moment, when I want to add a feature/fix a bug for one of those extensions, here's my workflow:

• Install the last version of the extension on one of the website via Modman
• Fix the bug/add a feature/test
• Manually copy the changes to a local folder that contains all my extensions
• Commit and push via GIT from this extension folder to Bitbucket (1 Bitbucket repo per module)
• Then the new version of the module can be installed via Modman

Important note: I'm using modman with hardcopy here, no symlink.

My biggest problem has been highlighted in bold: I want to be able to skip this step because it's a big cause of problems (some files are forgotten sometimes, wrong copy/paste, involves human action).

So, how can I improve my workflow in order to get rid of this manual copy/paste step ? I'm open to suggestions here.

Answer 1

I very often take the following approach which is pretty framework agnostic.

1. Check out the module you want to edit to /path/to/my/module
2. Create a branch for your piece of work (branched off of the relevant tag etc).
3. Commit work to this branch (don't push).

4. In your project, define a local repository to your local copy of the module. This is so that your project can pull in unpushed changes from your LFS.

   {
       "repositories": [
       {
           "type": "path",
           "url": "/path/to/my/module"
       }
   ],
   

5. You can then composer require your specific development branch (so long say your projects minimum-stability allows it).

   composer require namespace/module dev-branch-name-here
   

6. You commit in /path/to/my/module, composer update namespace/module in the project, see it install and test.

7. When you're complete squash your commits and push up.

I find this approach works well for M1 modules using https://github.com/Cotya/magento-composer-installer, as the symlinked install can be a pain sometimes and trip you up when adding new directories or paths which were previously not symlinked by modman.

Links that may interest

• https://lornajane.net/posts/2014/use-a-github-branch-as-a-composer-dependency
• https://lornajane.net/posts/2015/relying-on-a-dev-master-dependency-in-composer
• https://getcomposer.org/doc/05-repositories.md#path

Debugging

1. Use composer require namespace/module dev-branch-name-here -vvv to see the branches you can use locally.

2. Double check that minimum-stability has been set to dev in the project you're installing the module into.

3. Your requirements could not be resolved to an installable set

Found by reading Patrick Schwisow's comment here.

If other packages have requirements on the package you are changing, your development branch may fail to meet those requirements (which will result in "Your requirements could not be resolved to an installable set of packages."). To fix this, you can do an inline alias to that all other packages will see it as a specific version.

In short you can update your composer.json to force it to a specific version while developing, make it read like:

"namespace/module": "dev-branch-name-here as 1.2.3"

Answer 2

I'm using modman with hardcopy here, no symlink.

There's your problem. If you cannot change this setup for your shop deployments, consider working on shared extensions on a separate instance where you use modman with symlinks.

I use composer with the AOE composer installer to clone the extension repositories directly into .modman but installing modules from Git with modman works too I suppose. Either way you can work directly in the module Git repository.

Answer 3

So my idea here for you is to start working with composer even for Magento1. If you had your own packagist, which is not too hard to manage now that aws and google cloud is in place, or you can use public packagist. You would have "easy" access to newer versions in your Magento1 shops.

This means that when a newer version comes out you can composer update and it will automated the copy process for you.

Have a look at https://github.com/Cotya/magento-composer-installer for Magento1 via composer.

With this approach you can also directly work on the git repository under the vendor folder if you have it set to copy in the .git and so can push changed back to their repos without having a separate checkout. Though note you have to be careful here and make sure you know what branch you are on otherwise you can remove your code (done that a few times).