
Already there was something similar. Although this behavior was not a bug, it was fixed. The point was that composer could not install the package listed in composer.json, but replacing it:
Composer: Replace, Conflict & Forks Explained ,
Composer: Downloading? . But there is another behavior. It is obvious, but, I think, deprived of attention.
Composer aims to install a more recent version of the package. And it does not matter to him where he will find this package, in a private source of packages or on packagist.
Thus, if packagist and a private source of packages are used at the same time, then there is a possibility that the private package will be replaced with another one from packagist (if they have the same name and, for example, versions). Thus, there is a possibility that the package may be (if you take into account the Murphy's law, it will be) intentionally replaced by an intruder.
Conclusion : It is not safe to use packagist and a private source of packages at the same time.
')
If nothing is used with packagist, then you can simply
turn it
off . If both those and those packages are needed, then it is advisable to create your ecosystem using
satis or something like that.
You can also create an empty package on packagist so that no one can replace yours, but this does not agree with the basic ideas of packagist.
# 3509PS Played is simple. It is enough to create on github a repository with compser.json with one commit and a tag that is higher or equal to the version of your private package. Then add it to packagist.org. After that, upgrade and get a package with packagist, and not from a private repository.
An example of such a package. .
Script to playmkdir /tmp/test cd /tmp/test curl -sS https://getcomposer.org/installer | php mkdir ./substitute_private cd ./substitute_private echo '{"name": "my_substitute/my_substitute", "type": "library", "description": "substitute_private", "license": "LGPL-3.0+"}' > ./composer.json; git init git add . git commit -m 'initial commit' git tag '0.0.0' cd .. mkdir ./application cd ./application echo '{ "name": "my_application/my_application", "type": "application", "description": " ", "keywords": [], "license": "LGPL-3.0+", "repositories": [ {"packagist": false}, {"type": "git", "url": "../substitute_private"}], "require":{ "my_substitute/my_substitute": "~0.0" } }' > composer.json ../composer.phar install ../composer.phar update echo '------------> updated from(without packagist)' git --git-dir=./vendor/my_substitute/my_substitute/.git config --get remote.composer.url echo '{ "name": "my_application/my_application", "type": "application", "description": " ", "keywords": [], "license": "LGPL-3.0+", "repositories": [ {"type": "git", "url": "../substitute_private"}], "require":{ "my_substitute/my_substitute": "~0.0" } }' > composer.json ../composer.phar update echo '------------> updated from(with packagist)' git --git-dir=./vendor/my_substitute/my_substitute/.git config --get remote.composer.url
PPS The documentation says that packages from their own repositories take precedence over packagist packages, but this is true only when the version is specified as the branch ('dev-master'), not the version number (0.0.0).
PPPS Behavior changed. Now repositories have priority and packagist is the last.
github.com/composer/composer/pull/3982