New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Sort order improvement suggestion #779
Comments
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 Then I came up with - what I thought was - a better: I assume the same order that is used in In other words, because coming up with an order myself will be too much work, I would recommend asking for a modification of In other words, I understand your concerns, but I feel it would be too much work for too little gain. What do you think? |
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 I created a discussion (composer/composer#10073). Let's see what they answer. |
Sent a composer/composer#10089. Now we are waiting :) |
@localheinz, it's ok. PR is accepted (composer/composer#10089). Just wait for 2.2 release 😊 |
Released as |
I thought the schema is pulled automatically from the parent project 🙂 |
It is, but I failed to merge the corresponding pull request (#816) on time! |
Understood. Thanks! |
This is huge break for all projects using the original order :( |
Run composer normalize and you are good! |
@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. |
yes, but I maintain a lot of projects and now I need to reorder composer.json in every of them... Please do not make these changes often ;-) |
Sort ordering was changed in ergebnis/composer-normalize. See: ergebnis/composer-normalize#779 Change-Id: I5769f027d29d002d03e91b3786c169d8ddf06bb0 Issue-Link: https://project.pronovix.net/issues/6674-update_composer_jsons
Sort ordering was changed in ergebnis/composer-normalize. See: ergebnis/composer-normalize#779 Change-Id: I5769f027d29d002d03e91b3786c169d8ddf06bb0 Issue-Link: https://project.pronovix.net/issues/6674-update_composer_jsons
Sort ordering was changed in ergebnis/composer-normalize. See: ergebnis/composer-normalize#779 Change-Id: I5769f027d29d002d03e91b3786c169d8ddf06bb0 Issue-Link: https://project.pronovix.net/issues/6674-update_composer_jsons
Sort ordering was changed in ergebnis/composer-normalize. See: ergebnis/composer-normalize#779 Change-Id: I5769f027d29d002d03e91b3786c169d8ddf06bb0 Issue-Link: https://project.pronovix.net/issues/6674-update_composer_jsons
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:
And this project, in this case, offers the following logical scheme:
Personally, I think this formatting is illogical and makes it difficult to read the file.
I hope this information will help you.
The text was updated successfully, but these errors were encountered: