-
-
Notifications
You must be signed in to change notification settings - Fork 31
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
Make "paths that should not be sorted" configurable #704
Comments
Which property paths are these? |
@localheinz Which property paths should be added to the hardcoded exclusions? Off the top of my head I know of the following order-dependent paths:
|
Also using https://github.com/cweagans/composer-patches and experiencing the same issue: patches are re-ordered, but some of them need to be applied in a specific order. I'm currently working around this issue by defining my patches in a separate file (explained @ https://github.com/cweagans/composer-patches#using-an-external-patch-file). |
Hello, About composer-patches, a workaround is to use put number at the beginning of the description like in "drupal/core": {
"1 - BrowserTestBase::setUp() must be compatible with PHPUnit\\Framework\\TestCase::setUp() - https://www.drupal.org/project/drupal/issues/3182103": "https://git.drupalcode.org/project/drupal/-/merge_requests/28.patch"
}
Best regards, |
I also am experiencing problems with this in the "scripts" section - I define various commands to be run via the install and update hooks (via the "auto-scripts" block shown below), but these commands need to be in a specific order, whereas when normalized they are placed in alphabetical order which is not what we want! "scripts": {
"post-install-cmd": [
"@auto-scripts"
],
"post-update-cmd": [
"@auto-scripts"
],
"auto-scripts": {
"cache:clear": "symfony-cmd",
"doctrine:migrations:migrate -v": "symfony-cmd",
"bazinga:js-translation:dump assets --merge-domains --format=json": "symfony-cmd",
"assets:install %PUBLIC_DIR%": "symfony-cmd"
}
} When normalized changes the order and becomes: "scripts": {
"post-install-cmd": [
"@auto-scripts"
],
"post-update-cmd": [
"@auto-scripts"
],
"auto-scripts": {
"assets:install %PUBLIC_DIR%": "symfony-cmd",
"bazinga:js-translation:dump assets --merge-domains --format=json": "symfony-cmd",
"cache:clear": "symfony-cmd",
"doctrine:migrations:migrate -v": "symfony-cmd"
}
} |
@benr77 Working on this! |
I am releasing a temporary fix (see #875) as Let's keep this issue open until I have solved the problem! I apologize for any problems I have caused, and I thank you for opening these issues! Without your help, I would never even know about how different projects use |
Thanks for your efforts - it really is appreciated a lot! One point to consider - I see in the PR you are referring to In the Cheers! |
Thank you, @benr77! |
Hi, @localheinz don't blame yourself, this tool is amazing! Thanks for providing it in open source with free usage possible! |
Since this issue has not had any activity within the last 180 days, I have marked it as stale. I will close it if no further activity occurs within the next 14 days. |
I believe this issue is still unresolved, at least in the correct manner. Can we not close it please. |
I also cannot use this until scripts order normalization can be disabled. |
Can you share an example
Thank you! |
Fixing |
Fixing |
@localheinz I just don't want the scripts section "normalized" (alphabetized) at all. I would like to except the scripts section altogether. Same for |
Regarding Original
|
@FlorentTorregrosa @rafatwork @TravisCarden Fixing Does that make sense? |
Yes, it's safe to sort children of |
Regarding "scripts": {
"start": [
"Composer\\Config::disableProcessTimeout",
"php -S localhost:8080 -t public public/index.php"
],
"phpstan": "phpstan analyse .",
"phpcs": "phpcs",
"phpcbf": "phpcbf",
"rector-lint": "vendor/bin/rector process --dry-run",
"rector-fix": "vendor/bin/rector process"
}, Scripts are listed in logical blocks (build actions first, linters last). Linters are shown in order of importance/preference for the project. Each linter displays lint command first, fix command second. Order conveys information, I'm not fond of having it discarded blindly. On the other side, Would some generic opt-in/opt-out setting be a solution? Can it be flexible enough without adding too much complexity? {
"extra": {
"composer-normalize": {
"skip-keys": ["scripts", "scripts-descriptions", "extra.patches"]
}
}
} |
From my point of view, JSON objects are objects or maps - if the order of properties or keys matter in an object or a map, then something is broken by design. I am not judging, but I think it is a bad idea.
|
Hi, @localheinz, about #704 (comment), I confirm, direct children of So ok with you comment result. |
You have a point here. Original json.org page says:
ECMA-404 says:
And I don't think Composer has anything to say about order. I'd still appreciate a generic setting to customise behaviour for custom keys, but it's out of scope. |
@localheinz++ 😄 |
Some elements of
composer.json
are highly sensitive to order, such asextra.patches
with https://github.com/cweagans/composer-patches, which applies patches in the order specified and can therefore fail if it changes. See another example #699. I need a way to exclude arbitrary paths from sorting. I see that the current exclusions are hardcoded in\Ergebnis\Json\Normalizer\Vendor\Composer\ConfigHashNormalizer::PROPERTY_PATHS_THAT_SHOULD_NOT_BE_SORTED
. I would like this value to be configurable like the other options. I could take a stab at a PR. Alternatively, a few specific additions to the current hardcoded list would temporarily unblock my customers. I would gladly send a PR for that, too.extra.installer-paths
(Fix: AdjustComposerJsonNormalizer
to stop sortingextra.installer-paths
json-normalizer#777)extra.patches
(Fix: AdjustComposerJsonNormalizer
to stop sorting direct children ofextra.patches
json-normalizer#780)scripts.auto-scripts
(Fix: AdjustComposerJsonNormalizer
to stop sortingscripts.auto-scripts
json-normalizer#776)The text was updated successfully, but these errors were encountered: