composer : is there a way to specify a preference order for package repositories?

Question

I am working with a package vendorName/moduleName (a Magento extension) that is present on packagist and on firegento .

On my composer.json file, I have :

"require": {
   ....................,
   ...................,
  "vendorName/moduleName":"*"
},
"repositories": [
  ......................,
  ....................,
  {
    "type": "composer",
    "url": "https://packages.firegento.com"
  }
],

As Composer is downloaded pre-configured to use packagist.org , the vendorName/moduleName is loaded from packagist .

I would like to force vendorName/moduleName to be loaded from firegento .

I tried to add :

"repositories": [
  {
    "packagist": false
  },

but then, composer will no more search in packagist : that's not what I want.(as there are usefull packages in packagist too...)

I guess I could use

composer config --global --unset repositories.packagist

and then

composer config --global repositories.firegento composer https://packages.firegento.com
composer config --global repositories.packagist composer https://packagist.org

to add repositories in my prefered order (I'm not sure it works...).

Is there a better/simpler way to achieve my purpose ? I would prefer editing the composer.json more than running global config commands but it's maybe not possible.

Answer 1

Well,

I think I found the answer here :

Repository candidates are, in the end, only evaluated by their order of definition. Packagist is internally added as the last one by definition (though you can disable that) to ensure local copies are always preferred, if allowed by resolver settings.

That means that if I define the firegento repo in my composer.json , then composer will load the package vendorName/moduleName in firegento before packagist . I thought it was the opposite behaviour; I was wrong.

Another helpfull comment here :

Order of repository definitions matters. But composer will still search through all repositories regardless, because it could be that a repository that is defined later has a more recent version available of the package you are requiring.