Fix for Composer Global Config

[zogot]

Fix for Composer Global Config

Hey all. So I want to contribute towards renovate, specifically with the implementation of this discussion: #11980

So following the Contributing Guide, it says I should open a Discussion if there are doubts, or to get the maintainer(s) to agree to the proposed changes. Perhaps I'm missing something since it would be my first contribution.

Here are the changes that seem needed to solve this problem:

1. Add a detect.ts and matching spec to the lib/modules/manager/composer/ folder
2. Implement the method detectGlobalConfig similar to

   renovate/lib/modules/manager/npm/detect.ts

   Line 8 in eb8c080

   export async function detectGlobalConfig(): Promise<GlobalManagerConfig> {

   1. Since composers root config only allows setting repositories and config and I'm not sure where at the moment if any of the config options are even used currently, I want to initially focus on the 'repositories' key first. https://getcomposer.org/doc/03-cli.md#composer-home-config-json
   2. So this would look in the home directory for ~/.composer/config.json and extract the repositories key similar to the npmrc process.
3. Add registryUrls to GlobalManagerConfig
4. Mark registryUrls as mergeable here:

   renovate/lib/config/options/index.ts

   Line 1177 in b818b6b

   name: 'registryUrls',

This is before doing any code work yet and just reading the code. Probably gonna pick up this weekend. So any advice or things I might be missing or if there are points its important for me to consider, it would all be appreciated.

Some other things of note.

1. Perhaps is valuable instead of GlobalManagerConfig but instead have a type that only consists of the options with mergeable: true? This way, if we add a new parameter to options that is mergeable, we don't also have to update the GlobalManagerConfig.
2. Composer by default always attempts to read from COMPOSER_HOME/config.json when resolving packages, so I'm expecting that once the above changes are done, the actual running and resolving of the dependencies when using composer will work natively.

[rarkins]

No to (4). It sound cause a massive and unwelcome change of behavior to all managers

[zogot]

Ah, I misunderstood that mergeable was needed.

renovate/lib/config/utils.ts

Line 29 in b69416c

option.mergeable &&

Instead it actually merges above.

So should I just add to GlobalManagerConfig the registryUrls only?

[rarkins]

Describe (ideally not using Renovate terminology where possible) what information you hope to extract from the global composer config and how you would use it.

e.g. would it be the default list of registries to use instead of packagist.org? Plus their credentials? And then what if individual repos have different registries in their composer config?

[zogot]

So the intent is to pull out the repositories configuration from the global config file. Composer already uses this file and its repositories key as a means for resolving the repositories to search during composer commands.

Currently renovate only looks inside the Git Repositories composer.json repositories key, but should also use the definitions from the global config file.

As for the order of resolution, I will have to test on how composer does it currently to be sure. At least in their documentation they refer to resolving from the first matching repository unless specified to be non-canonical.

When resolving dependencies, packages are looked up from repositories from top to bottom, and by default, as soon as a package is found in one, Composer stops looking in other repositories.

https://getcomposer.org/doc/05-repositories.md#repository

It isn't clear from that write up in what order the global config is applied versus the Git Repositories specific definition, that I will test.

Also, from what I can see, Renovate currently doesnt define configuration support for canonical: false, perhaps this is a seperate ticket of work.

Full intent is to have the same repository being checked as it would actually update from.

[zogot]

Turns out, at least for my case, and probably others, the ability to define 1 repository in which to search for all packages from, can just be done with packageRules.

So I'm going to close this, since this solves the main problem exactly, wether its from a config file from composer, or a parameter in the config file for renovate, doesn't matter to me.

Here is the config I used, to just have this work:

packageRules: [
        { 
            matchDatasources: ["packagist"], 
            registryUrls: ["PACKAGE_REPO_URL_HERE"] 
        }
    ],