-
-
Notifications
You must be signed in to change notification settings - Fork 930
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add rule-empty-line-before rule #2309
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good job!
With new rule it won't be possible to enforce this style:
a {
display: block;
span {
}
strong {
}
}
a {
span {
}
strong {
}
}
There should be no empty lines before a rule, except if it's inside a block and after non-rule. I can enforce this style with:
{
"rules": {
"rule-non-nested-empty-line-before": ["never", {
"ignore": ["after-comment"]
}],
"rule-nested-empty-line-before": ["always", {
"except": ["first-nested", "after-rule"],
"ignore": ["after-comment"]
}]
}
}
How about new option except: ["inside-block-and-after-non-rule"]
?
Then I would be able enforce this style with:
{
"rules": {
"rule-empty-line-before": ["never", {
"except": ["inside-block-and-after-non-rule"],
"ignore": ["after-comment"]
}]
}
}
@@ -188,8 +188,7 @@ Here are all the rules within stylelint, grouped by the [*thing*](http://apps.wo | |||
|
|||
### Rule | |||
|
|||
- [`rule-nested-empty-line-before`](../../lib/rules/rule-nested-empty-line-before/README.md): Require or disallow an empty line before nested rules. | |||
- [`rule-non-nested-empty-line-before`](../../lib/rules/rule-non-nested-empty-line-before/README.md): Require or disallow an empty line before non-nested rules. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you think it's a good idea delete links to docs? These rules still in stylelint, despite the fact they are deprecated. When user will see a deprecation message, she may want to read what this rule for. But it will be very difficult to find.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point.
Can you create a PR that adds them back in for the other 13 deprecated rules? Please append "(deprecated)." to the end of the description.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will do today.
|
||
### `except: ["after-single-line-comment", "inside-block-and-after-rule", "first-nested"]` | ||
|
||
#### `"after-single-line-comment"` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why it's explicitly for a single-line comment?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This rule mimics the options from the previous two rules. Only the rule-nested...
had the after single line comment exception, as there was a specific request for that functionality.
@hudochenkov Thanks for the feedback.
We don't have the concept of I've added I think that covers off a few use-cases. I suggest we roll with what we have and then wait for requests for more idiosyncratic code styles. |
}, { | ||
code: "@media {}\n\na{}", | ||
description: "media rule", | ||
} ], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you add tests for nested rules either, please? New option affects both non-nested and nested rules.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nicely done!
@@ -188,8 +188,7 @@ Here are all the rules within stylelint, grouped by the [*thing*](http://apps.wo | |||
|
|||
### Rule | |||
|
|||
- [`rule-nested-empty-line-before`](../../lib/rules/rule-nested-empty-line-before/README.md): Require or disallow an empty line before nested rules. | |||
- [`rule-non-nested-empty-line-before`](../../lib/rules/rule-non-nested-empty-line-before/README.md): Require or disallow an empty line before non-nested rules. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will do today.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 I think the multi-line examples should be improved; otherwise looks good.
{} | ||
b | ||
{} | ||
``` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think these are confusing examples. Multi-line rules typically manifest as multiple lines of declarations — that's what people will recognize. Let's do that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done, or did you mean actually put a declaration inside the block?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jeddy3 As a user I would have better understanding if there would be declarations.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thing is, "multi-line" doesn't necessarily mean multiple declarations.
This is multi-line:
a {
color: red;
}
i.e. the rule spans multiple lines.
Perhaps a single declaration is the clearest?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From a user perspective your example with a single declaration isn't always a multi-line rule :) User might assume that this is single-line rule.
In fact you're right, of course.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jeddy3 You're right: that seems fine to me, too.
@davidtheclark I'm around this evening and can finish the release (woohoo!), if you're about to review stylelint/stylelint-config-standard#60 and feedback on the example changes here. FYI:
Are all ready-to-go against this branch. |
Closes #2229
I’ll update the rule to use the new empty line utils (to ignore shared-line comments) in
v8
.