One more note, I think the main downside of this is that it doesn't let you unset them without knowing which index it is present at anymore.. But I guess if that is important to people they can still use named repos then.

@Seldaek I guessed so, that this must be the reason for this to exist. At first I thought it has better control over "empty-object here but empty list over there" as this sometimes arise in composer files. Thank you for the explanation.

Good point regarding the removal. We could have a "host" / "url" option for removal but then the arguments start to become optional or similar shenanigans :D

I saw that the phpstan is pointing some things out. I will have a look at this later. Does it make sense to rebase to fix the CHANGELOG conflict or will you solve it eventually when it is merged as there will always be a conflict?

Feel free to rebase anyway to get the latest build fixes from main, BUT the changelog I usually do myself at release time so I'd say you can remove it completely that's fine by me.

@Seldaek I have been thinking about this whole repositories stuff again, and I am wondering if a cleaner solution overall would be to:

1. add an id/name/nickname field to all repository types (the schema already allows extra fields, so it'd be fully backwards compatible) to refer to repository by name for programmatic manipulation;
2. have a separate composer repositories command for manipulating repos, which
   • allows to have a good help screen without overloading the one for config;
   • could allow arguments for the various other fields of a repo (so no need to pass in JSON anymore);
   • could even interactively allow (re-)ordering;
   • could let you do things like composer repositories add --after otherrepoid …
   • gets rid of a bunch of special casing inside config handling logic;
3. deprecate the object notation, because
   • it requires hashmap implementations with stable keys to handle composer.json in other languages;
   • the conversion to numeric keys is confusing;
   • no sorting hapens even though numeric keys might make you think that is the case;
   • two ways of skinning the same animal;
4. maybe even auto-convert any existing object notations to array notations when re-serializing composer.json (still readable by older versions of Composer, as noted earlier)

@dzuelke yeah I think that all sounds great, it would mirror a bit the git remote command I guess (+ ordering..). Definitely would be more sensible than adding more hacks on top of the existing. But it also sounds like quite a bit of work..

I admit that I don't really like how git remote behaves in some cases but I see the gains of the feedback. Let me cook on that :)

@dzuelke @Seldaek I rewrote it to integrate a new command. I hopefully added enough test coverage (which is right now mostly happy-path). I also had to adjust the json schema and force "old" structures to the new one. I tried to only make it happen, when adding new repositories so it does not annoy too much. I made sure the name attribute for repositories is now always on top. This should make sure, they are sorted correctly so @localheinz does not have to sort it afterwards. I am very glad, that there already was a list-item-approach to disable packagist. Docs where AI powered, so if you want it to have more detailed or rewritten, I am happy to do that.

I am not sure about the php8.5 test. I do not see it directly why my changes would've bricked it. The pull request is now ready to review.

Thanks @JoshuaBehrens again, this is great work. I did tweak some things in the few commits above but I think now we're in a pretty good spot with this!

Only two areas of improvement left that I see:

• I'd like to tweak the formatting from:

    "repositories": [{
        "name": "foo",
        "type": "path",
        "url": "./"
    },{
        "packagist.org": false
    }]

to:

    "repositories": [
        {
            "name": "foo",
            "type": "path",
            "url": "./"
        }, {
            "packagist.org": false
        }
    ]

I think it would be more readable and more obvious that there is an array of objects?

• It would be great to support marking canonical true/false and adding only/exclude rules too https://getcomposer.org/doc/articles/repository-priorities.md#making-repositories-non-canonical but this is really nice to have and not essential, can still be achieved with the json config for now.

@Seldaek Thank you for the guidance and review. Happy to contribute :)

I can add canonical, only, exclude as options. I mean it is not that much different to the URL.

I understand and also like the syntax with the }, { but I doubt, that the PHP json_encode will print out anything like this. So I can have a look whether I can get RegEx to work with that, but eventually every fallback json_encode will break it. Doesn't it? Or shall I just preg_replace('/},\\s*{/g', '}, {', $content)-ish for everything?

@JoshuaBehrens if you want to do canonical/only/exclude feel free put please work on a new PR based on this one, as I'd rather get this one merged already. The newline stuff I am trying to look at it for a bit and if that doesn't work I'll skip, it's not that important.

Edit: OK not worth the hassle I think :D

Thank you for merging :)

Very nice work @JoshuaBehrens and @Seldaek!

Should the tests for the old object key syntax not maybe remain? They all got changed to the new name key variant, but that means there is now no guard against regressions in the handling of that.

Might also be useful to have tests for the "evil" case of old object key syntax but name in the value objects, maybe even with mismatching names, like so:

{
  "repositories": {
    "foo": {
      "name": "bar",
      "type": "composer",
      "url": "https://packagist.org/"
    }
  }
}

That sounds sensible.. @JoshuaBehrens if you have time for this be my guest 😇

Thank you for working on this! 🙏🏻

@Kocal you are welcome :)

After this version reach my CI I start getting tons of warning output from composer 2.9:

[...]
 - repositories.gravityforms/gravityforms : Matched a schema which it should not
 - repositories.gravityforms/gravityforms : Failed to match all schemas
 - repositories.gravityforms/gravityforms : Object value found, but a boolean is required
 - repositories.gravityforms/gravityforms : Does not have a value in the enumeration [false]
 - repositories.gravityforms/gravityforms : Failed to match at least one schema
 - repositories.dearflip/dearflip : Matched a schema which it should not
 - repositories.dearflip/dearflip : Failed to match all schemas
 - repositories.dearflip/dearflip : Object value found, but a boolean is required
 - repositories.dearflip/dearflip : Does not have a value in the enumeration [false]
 - repositories.dearflip/dearflip : Failed to match at least one schema
 [...]

I believe the below config is not that uncommon and the json error message are not as clear as they should (if you don't already know what & where to look for).

$ jq '{"repositories":.repositories}' .config/composer/config.json

{
  "repositories": {
    "wpengine/advanced-custom-fields-pro": {
      "type": "composer",
      "url": "https://connect.advancedcustomfields.com"
    },
    "freemius": {
      "type": "composer",
      "url": "https://composer.freemius.com/packages.json?authorization=Basic+...."
    },
    "dearflip/dearflip": {
      "name": "dearflip/dearflip",
      "type": "package",
      "package": {
        "name": "dearflip/dearflip",
        "version": "2.3.30",
        "type": "wordpress-plugin",
        "dist": {
          "url": "https://foo.gitlab.io/paid-plugins/tarballs/dflip-2.3.30.zip",
          "type": "zip"
        }
      }
    },
    "gravityforms/gravityforms": {
      "name": "gravityforms/gravityforms",
      "type": "package",
      "package": {
        "name": "gravityforms/gravityforms",
        "version": "2.8.16",
        "type": "wordpress-plugin",
        "dist": {
          "type": "zip",
          "url": "https://www.gravityhelp.com/wp-content/plugins/gravitymanager/api.php?op=get_plugin&slug=gravityforms&key=...."
        },
        "require": {
          "composer/installers": "^1.8|^2.1",
          "gotoandplay/gravityforms-composer-installer": "^2.3"
        }
      }
    },
    "wpackagist": {
      "type": "composer",
      "url": "https://wpackagist.org"
    }
  }
}

@drzraf the issue there is the name attribute inside the repository definition. It's either that or the object syntax.

Yeah you ideall convert repos to an array, remove the keys and move them to name properties then you can use the new repo command with it all