Adding a max to each rule?

[twelve17]

First of all, thanks to all the contributors to this project. :)

I did not realize, when I first ran these rules on my project, that the rules only ensure the presence of at least a single line-- meaning, you could have multiple empty lines before each of the token types, and it would be ok. In the case of where I am employed, there is a preference to not have padding around before blocks. I realized that these rules would not detect/fix such situations.

I saw that there is a general eslint no-multiple-empty-lines rule. I wondered if this plugin could support limiting the max lines around each token type, by way of a max attribute on each rule, defaulting to the current behavior if omitted?

[benkimpel]

Thanks for that doc fix PR, @twelve17.

Is the idea that you'd set max = 0 for before blocks for your company's use case?

At least with the way I'm thinking about it now I'm having trouble seeing much utility from a max-based implementation, because I think common use case is generally one line of padding with no-multiple-empty-lines handling the padding counts at a project level. BUT maybe we could have no-* versions of all these padding rules, like no-padding-around-before-blocks? That could let us remain focused on padding related to jest and not worry about counting empty lines.

Let me know your thoughts or if I've misunderstood.

[twelve17]

Hi @benkimpel 👋

Is the idea that you'd set max = 0 for before

Yes, that would be one use case, or max = 1 to prevent more than 1 line of padding.

And yes, perhaps using no-multiple-empty-lines along with this plugin could accomplish the trick. I just wasn't sure if there would be other areas in the codebase where multiple lines were ok. But perhaps it is better to go with this approach.

My only concern with no-padding-around-before-blocks was how it might complicate this library, because how it should handle if someone has specified both sets of a particular rule or rules (e.g. a no-padding-x along with a padding-x rule).

[benkimpel]

My only concern with no-padding-around-before-blocks was how it might complicate this library, because how it should handle if someone has specified both sets of a particular rule or rules (e.g. a no-padding-x along with a padding-x rule).

Great catch. That would be less than ideal and it would be easy for it to happen if someone were to use the base rules and then add a no-* rule on top.

@dangreenisrael (repo owner) is open to PRs if you think that adding a max option would provide some value. I'm not sure on the complexity since this plugin has been stable for a while and I've forgotten quite a bunch. 😬 But I'm around to bounce ideas off of if there's something to go after here.

[twelve17]

@benkimpel

repo owner) is open to PRs

I took a look at the sources a bit, and I def need to take that course on how to write eslint parsers 😅 . I think I will go down the route of no-multiple-empty-lines instead of throwing a bunch of work on other people's laps. Cheers!

[benkimpel]

Cool. Thanks again for the doc fix, @twelve17.

[twelve17]

You're welcome @benkimpel , it's the least I can do to help!