ci: correct commitlint usage

[TobiTenno]

old docs outdated conventional-changelog/commitlint#3947

[TobiTenno]

this time i tested locally to make sure this substitution from the removed --last flag worked

[TobiTenno]

@tukusejssirs @emagnier trying to fix up the last of what i broke, i've tested this a bit more on other repos since i last changed this

[tukusejssirs]

I’m just curious: what was wrong with --last?

In commitlint --help (using @commitlint/cli@19.2.1), I can see that --last/-l is also possible:

-l, --last           just analyze the last commit; applies if edit=false

That said, -f HEAD~1 -t HEAD should work exactly the same way.

[TobiTenno]

@tukusejssirs
that's what I thought was supposed to work as well, but when i tested locally, --last didn't exist for me

it's also not listed on their CLI reference

[TobiTenno]

ope! looks like they just readded it

[TobiTenno]

i'll retest locally and see if i can sort it out, i'll add the commitlint version print as well

[TobiTenno]

looks like the one i had installed is old. i'll get that updated and re-use --last. thanks for the extra eyes, @tukusejssirs

[TobiTenno]

@tukusejssirs let me know if you're satisfied by this current state.

to explain a bit, the prettier format -> dedupe -> sort would have to be in both the lint-staged cleanup and the dedupe on the check to ensure they both format out the same

[tukusejssirs]

At first, I’ve thought you sorted package*.json file alphabetically, however, after reading the README.md file of sort-package-json, I know it does it in a different order. I personally usually sort JSON files alphabetically using jq -S, however, I don’t about this much (I always use features of my IDE or grep to find the properties/values I want.

However, now the PR name and description does not match the changes made. You seem to prettify and sort package*.json files in the CI after deduping them. After vhanging them, I see no reason not to commit this PR.

[tukusejssirs]

Oh, and here the auto-merge goes: I wanted you change the PR desc, but not to slow you down by waiting on me to approve the changes … I have forgotten about the auto-merge being enabled.

[TobiTenno]

I'm happy to do another, but i'm not sure that I understand what you're asking. I change them in CI after deduping (as mentioned above) so that it's the same treatment they'd get from the commit hook to format -> dedupe -> sort so there'd be no git differences, which would fail the dedupe check

[TobiTenno]

I think the dedupe check (specifically the check, not the local part) just may not work out due to how it interferes with dependabot updates, and we have no way of forcing dependabot to dedupe

[tukusejssirs]

I'm happy to do another, but i'm not sure that I understand what you're asking. I change them in CI after deduping (as mentioned above) so that it's the same treatment they'd get from the commit hook to format -> dedupe -> sort so there'd be no git differences, which would fail the dedupe check

Nothing to do anymore. I was suggesting to update the OP which could be used in the MR commit message which is not the case on GitHub when squashing the changes (0c92112).

Anyway, I still don’t really like the the auto-merge option being enabled, as whenever I (or someone else) approve a PR, it might still have some nitpicks which I raise without requiring them, thus I let the PR author decide whether they implement them or not. Sometimes another reviewer (e.g. Etienne) might disagree with me, however, the PR would be already merged, thus a revert would be potentially required.