Sort order improvement suggestion

[andrey-helldar]

There are no discussions in this project, so do not judge strictly.

The screenshot below shows two options for formatting the file: on the left is the format I am trying to adhere to, and on the right is the processed by normalize.

I prefer to keep the "name" and "description" keys together as they contain a lot of text and separating them with a short "type" string is bad, in my opinion, as it spoils the look.

Also, I prefer to include the "config" block at the bottom of the file, as it refers to the composer rules, not the application.

I prefer to place the "support" block above the "require" block.

Thus, I try to divide all the keys into the following logical blocks:

- about the project
  - general information
    - name
    - description

  - project type
    - type
    - license

  - information for search
    - keywords
    - authors
    - support  

- dependencies
  - main dependencies
    - require
    - require-dev

  - autoload
    - autoload
    - autoload-dev

- composer config
  - config
  - minimum-stability
  - prefer-stable

- extended data
  - extra

And this project, in this case, offers the following logical scheme:

- about the project
  - general information
    - name

  - project type
    - type

  - general information
    - description

  - information for search
    - keywords

  - project type
    - license

  - information for search
    - authors

- dependencies
  - main dependencies
    - require
    - require-dev

- composer config
  - config

- extended data
  - extra

- dependencies
  - autoload
    - autoload
    - autoload-dev

- composer config
  - minimum-stability
  - prefer-stable

  - information for search
    - support

Personally, I think this formatting is illogical and makes it difficult to read the file.

I hope this information will help you.

[localheinz]

@andrey-helldar

Thank you for your feedback!

When I first started working on this project, I had something similar in mind: coming up with an order of fields that make sense, and then enforcing that order. When looking at the underlying composer-schema.json, I realized that there were a lot of fields that I had never used before, and that there were way to many of them to sensibly decide on an order.

Then I came up with - what I thought was - a better: I assume the same order that is used in schema.json, and when the schema allows additional fields, I will sort them at the end, alphabetically.

In other words, because coming up with an order myself will be too much work, I would recommend asking for a modification of composer-schema.json upstream, but I would assume that there would not be much interest in it.

In other words, I understand your concerns, but I feel it would be too much work for too little gain.

What do you think?

[andrey-helldar]

In my opinion, if you make your own sorting, it turns out that you will need to do it manually. This is bad.

So I'll agree with you and tell you what you are doing right by sticking to the composer-schema.json file. This adds stability to the project.

I created a discussion (composer/composer#10073). Let's see what they answer.

[andrey-helldar]

Sent a composer/composer#10089. Now we are waiting :)

[andrey-helldar]

@localheinz, it's ok. PR is accepted (composer/composer#10089). Just wait for 2.2 release 😊

[localheinz]

@andrey-helldar

Released as ergebnis/composer-normalize:2.17.0, apologies for the delay!

[andrey-helldar]

I thought the schema is pulled automatically from the parent project 🙂

[localheinz]

@andrey-helldar

It is, but I failed to merge the corresponding pull request (#816) on time!

[andrey-helldar]

Understood. Thanks!

[mvorisek]

This is huge break for all projects using the original order :(

[localheinz]

@mvorisek

Run

composer normalize

and you are good!

[andrey-helldar]

@mvorisek, even without a normalizer, there are no problems. This scheme only sets the requirements for the project, nothing more. Therefore, changing the order in it does not play any role for the composer himself.