You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
But the goal of yamllint is to lint the form of YAML, not the content or its structure. We could imagine many new rules to check the max number of items (what you propose), or the type of values, or that all strings contain a substring, or that all keys match a regex, etc. But the purpose of yamllint is to be focused on YAML itself, so I'm not favorable to adding such content-oriented rules.
In this, i'm referring solely to the form of the YAML..
Currently "forbid" will disallow simple one-liners like { key: "opt-out", values: ["true"] } whereas this is something we can consider 'cleaner' than an expanded form, while still requiring for long arrays to be expanded fully, e.g.
Thanks for the clarification! Sorry, I initially misunderstood your proposal.
→ You want to be able to force sequences to be in block-style (i.e. forbid flow-style) if they contain more than n elements. And the same for mappings, I suppose.
Indeed this is about the form of the YAML, so it could be accepted. But it seems a bit a "niche" use case, and the goal (have "cleaner" and "easier to read" data) can maybe be achieved using the line-length rule?
Rule feature to expand existing
brackets
to allow flow-style brackets for arrays up to n items, but forbid for longer than that.e.g. { forbid: { max_size: 3 } }
PASS
[ 1, 2, 3 ]
FAIL
[ 1, 2, 3, 4, 5 ]
May also want to extend to allowing only certain character lengths in flow-style, or forbidding nested objects while allowing primitives.
The text was updated successfully, but these errors were encountered: