Developing with Composer path repository and merge plugin, how to avoid update of composer.lock?

Question

Here is the situation.

I'm developing package-a which depends on package-b. The latter is hosted on bitbucket:

projects/
├── package-a/
├── package-b/

I need to make changes to package-b and see the results without pushing the code and do a composer update. Then, when finishing the work, I'll push a new tag and deploy package-a to the production server.

So I ended up using composer-merge-pluging and Composer path repositories, with the following configuration:

Here is the composer.json of package-a:

{
    "name": "my/package-a",
    "require": {
        "my/package-b": "^1.0"
    },
    "repositories": [
        {
            "type": "vcs",
            "url":  "[email protected]:my/package-b.git"
        }
    ],
    "extra": {
        "merge-plugin": {
            "include": [
                "composer.local.json"
            ]
        },
        "replace": true
    }
}

This file will include composer.local.json (only in my local machine! this file is not committed nor pushed to the production server), where I'm saying "use the dev-master version and the path repository":

{
    "require": {
        "my/package-b": "dev-master"
    },
    "repositories": [
        {
            "type": "path",
            "url":  "../package-b"
        }
    ]
}

The setup is fine in the sense that if I run composer install from package-a then package-b is symlinked and I can work directly on it.

But when I deploy package-a to my server using Deployer (versioning the composer.lock file too) it does a composer install but lock file contains a reference to package-b@dev-master using the path repository (and this is wrong).

Any idea how to solve this problem? I'm sure it's a common one but I can't get it.

Answer 1

To aide in development of packages, you can have composer install the source of package-b instead of the distribution.

Inside package-a:

rm -rf vendor/package-b
composer update --prefer-source package-b

This should do a clone of package-b into the vendor directory. From there, you can make the changes in vendor/package-b and see the changes reflected inside the current application (package-a).

When you're happy with the changes in package-b, you can commit the changes off. Your work with package-b will be done.

Before deploying package-a, you'll want to make sure that the commit for project-b that is referenced in your composer.lock file has been pushed up to the remote (bitbucket you said) and is up to date.

You may end up not even needing a separate checkout of project-b at all. Do any needed work inside of project-a. (Just a possibility)

---

One thing that will make your life remarkably easier will be to start tagging releases of your packages.

Rather than chasing separate moving targets, start thinking of the features you need to add to package-b to make the new functionality in package-a work... add in that functionality, and release it. Then your work with package-a is "update to the new release of package-b so I can use cool new functionality x"

It'll help your release process, improve feature planning, and generally make for a cleaner experience.