Add max-lines

[pburkindine]

What is the problem you're trying to solve?

Developers create very large S/CSS files which cannot be maintained

What solution would you like to see?

Rule to set an error when the length of a file exceeds a given integer, same concept as tslint:max-file-line-count

[jeddy3]

@pburkindine Thanks for the suggestion.

There is also a similar rule in ESLint.

I think we'd want to call the rule max-lines. It'll then align with our naming conventions and fit well with the likes of max-empty-lines.

• Name: max-lines
• Primary option: int
• Secondary options: none
• Message: Expected no more than ${max} ${max === 1 ? "line" : "lines"}
• Description: "Limit the number of lines."
• Section: "Limit language features" -> "General / Sheet"

Feel free to contribute this rule.

[Maxim-Mazurok]

I'm going to work on this one, if nobody else is working already.

[Maxim-Mazurok]

I'm thinking about adding ignore: ["comments", "empty-lines"] to this new rule. But those options are not requested as of now, but they present in eslint max-lines rule. So, @jeddy3, should I include those options, or wait for the request?

[jeddy3]

So, @jeddy3, should I include those options, or wait for the request?

As a rule of thumb, we generally wait until an option is requested before adding it. So, let's just add the plain rule for now.

[cahamilton]

Hey there. I hope you don't mind me hijacking this issue - it's a rule I'd like to start enforcing myself in my projects.

I've pieced together a really basic implementation in #4021, which should cover the basic requirement for enforcing line count (no secondary options). Let me know if theres any issues with it!

[Maxim-Mazurok]

@cahamilton, sure, I don't mind at all. I was trying to implement this, but haven't found an optimal way to do this while following general approach used in the code base for other rules.
And then, I switched to other project, without stylelint, so I'm not sure if I'm going to finish this at all.
I will take a look at your PR, thanks!

[cahamilton]

@evilebottnawi @hudochenkov @jeddy3 @Maxim-Mazurok

Working through the PR changes now and was wondering, how do we feel about updating the error message to something like the following?

Expected ${max} ${max === 1 ? "line" : "lines"} max. Actual is ${actual} lines (or something similar).

Would help give more accurate test assertions considering things like different syntaxes, mixed line endings etc.

Would also be somewhat more inline with error messaging found in ESLint, which uses:
File must be at most {{max}} lines long. It's {{actual}} lines long.

[alexander-akait]

Yep, message from eslint looks better

[jeddy3]

Would help give more accurate test assertions considering things like different syntaxes, mixed line endings etc.

That makes sense. How's about we standardise on "Found ..." as it's shorter and a single word e.g.

Expected no more than ${max} ${max === 1 ? "line" : "lines"}. Found ${found} ${found === 1 ? "line" : "lines"}.

The "Expected ..." convention is shared across all stylelint rules. And the "no more than" is shared across the *-max-* rules, so we should stick with them for this rule.

[pburkindine]

@jeddy3 @Maxim-Mazurok @cahamilton any update here?

[alexander-akait]

PR welcome, it is open source

[Maxim-Mazurok]

No, @pburkindine sorry, I'm not using stylelint currently. Hopefully, @cahamilton will take care of it in #4021

[jeddy3]

The community is welcome to create a plugin for this.

[alexander-akait]

@jeddy3 I think this rule more about potential problems rather than stylistics, preventing many lines can help to maintenance big code base, yep, it sounds like stylistics, but this is not actually an indication of style, it's more about how to write code

[github-actions]

This issue is older than one month. Please ask before opening a pull request, as it may no longer be relevant.