Aha, it seems like there is not yet a consensus of what the use statement order should be
https://www.drupal.org/project/coding_standards/issues/1624564
📌
Coding standards for "use" statements
RTBC
It makes sence that I implement it as gitlab-ci wants it (even if we don't really agree with it at the moment) and change once/if the standard gets in place in gitlab-ci.
I push a revert of the alphabetical sort now to the 1.0.x
Maybe its a bug in gitlab-ci phpcs? Worst case I could make a skip for that phpcs rule but thats is not ideal.
Yes, but that is the thing. If I make phpcs locally happy (with the alphabetical sort order) gitlab-ci complains and vice versa.
Phpcs locally, and for you obviously, want it sorted one way. Gitlab-ci want is sorted an other. Having different views of how uppercase/lowercase fits in the alphabetical order.
@vishal.kadam
Good inputs. I have now taken care of the suggested changes.
But, the phpcs issue is a mysterium. When running phpcs --standard=Drupal,DrupalPractice --extensions=php,module,inc,install,test,profile,theme,css,info,txt,md,yml autologout_alterable/ I also got the "Use statements should be sorted alphabetically." error and the order that has been updated now makes sence for a human.
But ci in gitlabs has a different opinion of what "sorted alphabetically" means.
see: https://git.drupalcode.org/project/autologout_alterable/-/jobs/3129616
It seems like in gitlab ci "autologout_alterable" should be sorted after "Core", e.g. uppercase "C" goes before lowercase "a". Could that be system dependent?
I would very much keep it in the now updated order, which also is what phpstorm ide autoformat it to. But at the same time I dont want gitlab ci to fail on phpcs. Any idea how to resolve it?
andersmosshall → created an issue.
Proposed solution via patch file.
andersmosshall → created an issue.
andersmosshall → created an issue.
A proposed solution patch to this issue. See Proposed resolution section.
andersmosshall → created an issue.
Also noted this issue. There is a change record for ajax.js in core here.
https://www.drupal.org/node/3293812 →
Effectivly the suggested solution is to store the original success callback, do your processing and then call the original callback again.
I created a patch doing just that.