Use a package fork in a composer dependency

Question

I'm developing a laravel package (lets call it package A) and it requires another package (package B https://github.com/dropbox/dropbox-sdk-php).

I've made a fork of package B (https://github.com/EmilioBravo/dropbox-sdk-php), made some changes in a new branch "fix64" and added my GitHub repo as a repository in composer.json of package A as indicated in the composer docs:

"repositories": [
    {
        "type": "vcs",
        "url": "https://github.com/EmilioBravo/dropbox-sdk-php"
    }
],
"require": {
    "php": ">=5.4.0",
    "illuminate/support": "4.2.*",
    "dropbox/dropbox-sdk": "dev-fix64"
},

If I call composer update from within the package A it downloads my fork correctly, but, If im using package A as a dependency in another project (Project C) and call composer update from it, composer says it can't find dev-fix64.

Problem 1

- emilio-bravo/platform dev-dropboxfix requires dropbox/dropbox-sdk dev-fix64 -> no matching package found.

• emilio-bravo/platform dev-dropboxfix requires dropbox/dropbox-sdk dev-fix64 -> no matching package found.

• Installation request for emilio-bravo/platform dev-dropboxfix -> satisfiable by emilio-bravo/platform[dev-dropboxfix].

Only if I add my repo as repositories in the project C composer.json it finds my fork's branch.

The other way around it I've found is cloning my fork into a satis repository.

But it doesn't feel right. How can I get composer to find my fork from GitHub?

Answer 1

Adding the custom repository to the main project is the only way to make Composer aware of the new source.

And it is intentionally done this way, because otherwise repos could add repos could add repos... without a guarantee to have a finite list of repos.

Also, adding a repo does not make any statement about which software is to be found there, Composer will scan every tag and branch. In theory a repository can have another branch for a completely different, well-known package, offering a newer version of it, and add some malicious behavior.

Composer in general seems to be pretty well suited regarding protection against remote code execution, with the exception of an uninformed human making bad decisions.

So if you find a bug in a package published on packagist.org, the best way for everyone is to propose a pull request. The second best way would be to fork the project under a new name and publish it on packagist.org as well. Patching the problem using a forked repo with the same project name and pointing Composer to it is the worst solution and generally only feasible for dependencies of your own projects.