eslint: Option to tolerate single lines with padded blocks
What rule do you want to change?
“padded-blocks”
Does this change cause the rule to produce more or fewer warnings?
fewer
How will the change be implemented? (New option, new default behavior, etc.)?
New option. Could be similar to { "allExcept": ["singleLine"] } in JSCS (http://jscs.info/rule/requirePaddingNewLinesAfterBlocks)
Please provide some example code that this change will affect:
if (cond) { doSomething(); }
What does the rule currently do for this code?
Warning / Error: “Block must be padded by blank lines.”
What will the rule do after it’s changed?
Emits no warning if using { "allExcept": ["singleLine"] } option
About this issue
- Original URL
- State: closed
- Created 8 years ago
- Reactions: 6
- Comments: 31 (25 by maintainers)
Commits related to this issue
- Update eslint to the latest version 🚀 (#10) ## The devDependency [eslint](https://github.com/eslint/eslint) was updated from `5.12.1` to `5.14.0`. This version is **not covered** by your **current ... — committed to futurestudio/hapi-geo-locate by greenkeeper[bot] 5 years ago
- Update eslint to the latest version 🚀 (#3949) ## The devDependency [eslint](https://github.com/eslint/eslint) was updated from `5.7.0` to `5.14.0`. This version is **not covered** by your **current... — committed to stylelint/stylelint by greenkeeper[bot] 5 years ago
This seems like a good idea, but I don’t think
allExcept: ["singleLine"]is a good API for it. An array containing a single string seems like an inelegant API to me; I think it would be better to have explicit object options instead.How about something like this?
I know this has been accepted a while back, but I have a new proposal for this. How about deprecating existing
blocks,classesandswitchesoptions, and addingexceptionsoption of type Array, that acceptsASTNode|"single"|"block"? That should cover all JSCS cases, and bring this rule inline with other rules we have.I’m going to work on this issue.
I wonder if, to get the ball rolling, we could just implement
singleLine(which seems like the one that is most useful) now and wait and see if there are requests for the other options in the future. Since they’re all behind their own unique flags and off by default, they can all be implemented independently and none are breaking changes.I can champion this change if the above sounds good!
Ah, thanks. I forgot about that. Yes, I would prefer syntax suggested by @not-an-aardvark It’s more inline with other rules we have.
Apologies for dropping the ball as the champion of this issue. Given that this is a JSCS compatibility issue, I would like to see this through.
While I appreciate @ilyavolodin’s solution, I would like to propose we go with the previous solution as described here. We can always change the rule in the future if need be, and this would buy us JSCS compat without having to make major changes to the implementation.
If this is amenable to the team, I’m happy to make a PR myself.
@eslint/eslint-team I’d really like to get this implemented. Given the complexities that are introduced by https://github.com/eslint/eslint/issues/7145#issuecomment-281882639 that I’ve outlined in my previous comment, I wonder if it would be beneficial to implement either the proposal in https://github.com/eslint/eslint/issues/7145#issuecomment-258700883 or to solve this with the proposal in https://github.com/eslint/eslint/issues/7775?
To reiterate, my goal here is JSCS compatibility. Once we have that, we can always iterate!