Use packet fork depending on composer

Question

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

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

"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 the composer update from package A, it loads my plug correctly, but if im uses package A as a dependency in another project (Project C) and the composer is called from it, the composer says that he cannot 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 -> execute emilio-bravo / platform [dev-dropboxfix].

Only if I add my repo as repositories in the C composer.json project will it find the fork branch.

Another way I found is to clone my fork into the satis repository.

But this is not so. How can I get the composer to find my fork from GitHub?

Answer 1

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

And this is intentionally done in this way, because otherwise repos can add repos, can add repos ... without guaranteeing to have a finite list of repositories.

In addition, adding a repo does not make any statements about what software will be found there, Composer will check every tag and branch. Theoretically, the repository may have a different branch for a completely different, well-known package, offering a newer version and adding some malicious actions.

The composer as a whole, apparently, is very suitable for protection against remote code execution, except that a person who does not know a person makes bad decisions.

So, if you find a bug in a package published on packagist.org, the best way for everyone is to offer a transfer request. The second best way is to fork the project under a new name and publish it on packagist.org. Fixing a problem using a forked repo with the same project name and pointing to Composer is the worst solution and is usually only possible for the dependencies of your own projects.