Hello,

I'm not very favorable to such a change, because yamllint aims to lint the form, not the content:

• Ensuring a given order for keys of a mapping is about form, because YAML mapping keys do not have an order, per the YAML specification. Expecting an alphabetical sorting of keys is just about style → what a linter does.
• Ensuring a sort order for list values is about content: yamllint would impose to change the effective value of data ([h, e, l, l, o] is not the same as [e, h, l, l, o]).

Additionally, the way heterogenous item types (e.g. [false, 1, "2", {3: 4}]) should be handled is very subjective and probably tricky.

Any kind of list sorting needs to be based on content-specific policies. It isn't really feasible to implement such a thing within a linter.

I do agree with the points @adrienverge raises, and is very much content-specific as @mwgamble notes. I do still have the need and cast an eye towards yamllint as the tool since it already has the yaml parsed into a DOM where I felt it might be an easy feature to add...

Maybe we'll just write our own parser to implement this check for our context..

Hello,
Any update about this feature?

I agree that someone do not want to have list sorted, but this rule is similar to key-ordering rule, which is disabled by default.

I think that it would be worthy to have it, disabled by default. And actually there is a PR for this feature, but what is the reason it was not merged?

The lack of some test cases? I'm not sure but maybe @adrienverge you should write it explicitly, what should be added to the PR to be able to merge it.

Hello,

I tried to make it clear in my previous comment: #454 (comment) but I can try to write it differently. Yamllint aims to lint the form, not the content. The rule key-ordering is about the form (data-wise {a: 1, b: 2} is the same as {b: 2, a: 1}), whereas a rule to sort values would be about the content, i.e. forcing data to respect some arbitrary rules ([a, b] is not the same as [b, a]).