Fix overwriting a list repository addressed by numeric index in config command - #13025

There is a behaviour change here which looks wrong

Have the composer.json

{
    "name": "acme/package",
    "repositories": [
        {
            "name": "a",
            "type": "path",
            "url": "../a"
        },
        {
            "name": "b",
            "type": "path",
            "url": "../b"
        },
        {
            "name": "c",
            "type": "composer",
            "url": "https://c.test"
        }
    ]
}

Run command

bin/composer repo add 0 vcs https://moved.test --before 1

On main this fails with

In JsonConfigSource.php line 172:

  The referenced repository "1" does not exist.

In this branch this rewrites the composer.json to

{
    "name": "acme/package",
    "repositories": [
        {
            "name": "b",
            "type": "path",
            "url": "../b"
        },
        {
            "type": "vcs",
            "url": "https://moved.test"
        },
        {
            "name": "c",
            "type": "composer",
            "url": "https://c.test"
        }
    ]
}

Which I am not sure is correct

I believe this is broken both in JsonConfigSource::insertRepository and JsonManipulator::insertRepository

Good catch, that was wrong. insertRepository() was resolving the new repository's name to a position of its own, so 0 deleted the entry at position 0. Since --before/--after already state the position, the name argument there only ever names the new repository — it is now resolved by name only (findRepositoryKey($name, false) / findRepositoryIndex($repos, $name, false)), so nothing gets removed.

Your exact reproduction is now a test, and with named repositories it errors instead — see the reply on the docs thread for the rule.

Correct, it was broken in both. Fixed in JsonManipulator::insertRepository() and in the JsonConfigSource::insertRepository() fallback, which now takes the same $allowIndex flag.

While adding your set-url by position case I found the JsonConfigSource::setRepositoryUrl() fallback had the same class of bug — it compared $name === $index, string against int, so it never matched anything in a list. That one is fixed too.

This test case here changes the behaviour

public function testAddRepositoryByNumericKeyInObjectFormatKeepsItsPosition(): void
    {
        $manipulator = new JsonManipulator('{
    "repositories": {
        "foo": {
            "type": "composer",
            "url": "https://foo.test"
        },
        "1": {
            "type": "path",
            "url": "../one"
        },
        "bar": {
            "type": "composer",
            "url": "https://bar.test"
        }
    }
}');

        self::assertTrue($manipulator->addRepository('1', ['type' => 'composer', 'url' => 'https://replaced.test'], false));
        self::assertSame(
            ['https://replaced.test', 'https://foo.test', '../one', 'https://bar.test'],
            array_column(JsonFile::parseJson($manipulator->getContents())['repositories'], 'url')
        );
    }

In your branch this overwrites an existing entry and afterwards the repositories section only has three entries. No matter whether append is set to true/false

This one is intentional, and I would like to keep it. In the object format a numeric key is a name, so "1" should be replaced rather than duplicated — the reason it was not is the same int-vs-string bug as elsewhere: casting a stdClass to array yields int keys, so $repositoryIndex === $name never matched. #12623 is the list-format symptom of it; this is the object-format one, and the reporter's own target JSON in that issue uses "0"/"1" keys.

Your case is now a test (testAddRepositoryByNumericKeyInObjectFormatReplacesTheNamedEntry), asserting the three-entry result. Note it does not warn or throw: this resolves by name, not by position, so the new rule does not apply to it.

This is only true if there are no Composer repositories configured in the global composer.json. If there are for instance two entries in the global composer.json then these have index 0, 1 in the brackets and the entries in the local composer.json start with index 2

You are right, and it is worse than that — the numbers are not offset, they are reordered. Config::merge() reverses, re-keys on collision, then reverses back, so with two repositories in the global config.json and three locally, repo list prints:

[4] path ../l0
[3] path ../l1
[2] path ../l2
[0] composer https://g1.test
[1] composer https://g2.test

while config repositories.0 still targets ../l0, the first entry of the local file.

That killed the justification for the feature, so the rule is now:

• a repository is addressed by its name
• a numeric key falls back to the position in the file being modified, and warns that this is unreliable
• if the entry at that position has a name, it is refused with The repository at position 1 is named "b", address it by that name instead.

The check lives in one place (BaseConfigCommand::validateRepositoryKey()) for both the config and repo commands, and applies to whichever argument does the addressing — which for --before/--after is the ordering option, not the new name. The docs no longer claim the number is what repo list shows.

One inconsistency I deliberately left: repo get-url N still resolves against the merged config, so it can disagree with repo set-url N. That is pre-existing on the read side and we kept this change to writes only.

When I add the test case below

'set-url by position' => [
                static function (JsonConfigSource $source): void {
                    $source->setRepositoryUrl('1', 'https://updated.test');
                },
                [['name' => 'foo', 'type' => 'vcs', 'url' => 'https://foo.test'], ['type' => 'path', 'url' => 'https://updated.test']],
            ],

Then I run into

Composer\Pcre\PcreException : preg_match(): failed executing "{(?(DEFINE)
       (?<number>    -? (?= [1-9]|0(?!\d) ) \d++ (?:\.\d++)? (?:[eE] [+-]?+ \d++)? )
       (?<boolean>   true | false | null )
       (?<string>    " (?:[^"\\]*+ | \\ ["\\bfnrt\/] | \\ u [0-9A-Fa-f]{4} )* " )
       (?<array>     \[  (?:  (?&json) \s*+ (?: , (?&json) \s*+ )*+  )?+  \s*+ \] )
       (?<pair>      \s*+ (?&string) \s*+ : (?&json) \s*+ )
       (?<object>    \{  (?:  (?&pair)  (?: , (?&pair)  )*+  )?+  \s*+ \} )
       (?<json>      \s*+ (?: (?&number) | (?&boolean) | (?&string) | (?&array) | (?&object) ) )
    )^(?P<start>\s*\{\s*(?:(?&string)\s*:\s*(?&json)\s*,\s*)*?"repositories"\s*:\s*\[\s*((?&json)\s*+,\s*+){1})(?P<repository>(?&object))(?P<end>.*)}sx": Backtrack limit exhausted

I think the PcreException was there before but somehow the code changes here make it possible/easier to reach the code path?

Reproduced — thanks, that was a real gap. setRepositoryUrl() was the only one of the six regex methods without a PREG_BACKTRACK_LIMIT_ERROR guard, so it threw instead of degrading to the whole-file fallback. It now catches it like the others.

The fallback it degrades to was also broken ($name === $index, string vs int, never matched in a list), so your case would have silently done nothing even with the guard. Both are fixed and your set-url by position case is in provideRepositoryFallback().

Your reading is right: pre-existing, but this branch made it reachable. On main setRepositoryUrl('1', ...) never resolved a numeric name at all, so it returned early and the regex was never built. Now that it resolves, the unguarded Preg::isMatch() is hit — which is exactly what your test surfaced.

Nice! Only downside is that we now have three methods (this one, findRepositoryIndex, findRepositoryKey) which all do more or less the same thing

5f4852f unifies that, ish.. It kinda replaced one with another one, I am not even sure anymore :D