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

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. This pairs well with "prefer-stable": true

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"

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.

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).