Composer package registry re-orders package data

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

• Close this issue

Summary

Gitlab's Composer package registry has a behaviour where package data from composer.json is sorted unexpectedly and inconsistently with the source data.

The behaviour appears to be that key:value pairs are ordered by key length.

For composer.json values which require an expected ordering, this behaviour may cause breakage.

Steps to reproduce

• Publish a package using Gitlab's Composer package registry
• Compare the metadata of the source composer.json and the version available from the package registry
• Values will be ordered according to the length of the key?!

Example Project

https://gitlab.com/gl364606/gl364606/

What is the current bug behavior?

The JSON output is modified in ways which can cause unexpected behaviour in consuming applications.

A common tool which demonstrates this impact is cweagans/composer-patches. Since patches may need application in a specific order, the re-ordering of JSON data can cause this tool to fail when patches are applied.

Input:

{
    "require": {
          "php": "^8.0",
          "ext-json": "*",
          "chriskonnertz/open-graph": "^2.0",
          "laravel/framework": "^8.0",
          "spatie/schema-org": "^3.5.0"
    },
    "require-dev": {
          "brainmaestro/composer-git-hooks": "^2.8.2",
          "friendsofphp/php-cs-fixer": "^3.0.0",
          "phpunit/phpunit": "^9.5"
    }
}

Output:

{
        "require": {
          "php": "^8.0",
          "ext-json": "*",
          "laravel/framework": "^8.0",
          "spatie/schema-org": "^3.5.0",
          "chriskonnertz/open-graph": "^2.0"
        },
        "require-dev": {
          "phpunit/phpunit": "^9.5",
          "friendsofphp/php-cs-fixer": "^3.0.0",
          "brainmaestro/composer-git-hooks": "^2.8.2"
        }
}

What is the expected correct behavior?

The JSON input at publication time (ie that in the published tag) should be accurately represented in the data output by the package registry.

Relevant logs and/or screenshots

• Failing job example (install via Gitlab package registry): https://gitlab.com/gl364606/gl364606/-/jobs/2559918847
• Passing job example (install via git): https://gitlab.com/gl364606/gl364606/-/jobs/2559918846
• Source package information: https://gitlab.com/gl364606/gl364606/-/blob/main/composer.json
• Re-ordered package information: https://gitlab.com/api/v4/group/54151172/-/packages/composer/xurizaemon/gitlabsortorder%248d74dd74c36c2a6a5db97a2309e71fea29e62144.json

Input:

Output:

Behaviour also visible at this (non gitlab.com) URL:

• Input: https://git.fotocadeau.nl/packages/data/-/blob/1.17.62/composer.json
• Output: https://git.fotocadeau.nl/api/v4/group/21/-/packages/composer/fotocadeau/data%2440796b83b6f99ef8cedeaa887b35da83804af8c9.json (refer to 1.17.62 entry)

Output of checks

This bug happens on GitLab.com.

Possible fixes

Not yet identified.