Skip to content
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

Merged
merged 6 commits into from Feb 2, 2017
Merged
Show file tree
Hide file tree
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
3 changes: 1 addition & 2 deletions docs/user-guide/example-config.md
Expand Up @@ -114,8 +114,7 @@ You might want to learn a little about [how rules are named and how they work to
"property-no-unknown": true,
"property-no-vendor-prefix": true,
"property-whitelist": string|[],
"rule-nested-empty-line-before": "always"|"never",
"rule-non-nested-empty-line-before": "always"|"never",
"rule-empty-line-before": "always"|"never"|"always-multi-line"|"never-multi-line",
"selector-attribute-brackets-space-inside": "always"|"never",
"selector-attribute-operator-blacklist": string|[],
"selector-attribute-operator-space-after": "always"|"never",
Expand Down
3 changes: 1 addition & 2 deletions docs/user-guide/rules.md
Expand Up @@ -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.
- [`rule-empty-line-before`](../../lib/rules/rule-empty-line-before/README.md): Require or disallow an empty line before rules.

Copy link
Member

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.

Copy link
Member Author

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will do today.

### Media feature

Expand Down
2 changes: 2 additions & 0 deletions lib/rules/index.js
Expand Up @@ -116,6 +116,7 @@ const propertyNoUnknown = require("./property-no-unknown")
const propertyNoVendorPrefix = require("./property-no-vendor-prefix")
const propertyWhitelist = require("./property-whitelist")
const rootNoStandardProperties = require("./root-no-standard-properties")
const ruleEmptyLineBefore = require("./rule-empty-line-before")
const ruleNestedEmptyLineBefore = require("./rule-nested-empty-line-before")
const ruleNonNestedEmptyLineBefore = require("./rule-non-nested-empty-line-before")
const selectorAttributeBracketsSpaceInside = require("./selector-attribute-brackets-space-inside")
Expand Down Expand Up @@ -291,6 +292,7 @@ module.exports = {
"property-no-vendor-prefix": propertyNoVendorPrefix,
"property-whitelist": propertyWhitelist,
"root-no-standard-properties": rootNoStandardProperties,
"rule-empty-line-before": ruleEmptyLineBefore,
"rule-nested-empty-line-before": ruleNestedEmptyLineBefore,
"rule-non-nested-empty-line-before": ruleNonNestedEmptyLineBefore,
"selector-attribute-brackets-space-inside": selectorAttributeBracketsSpaceInside,
Expand Down
223 changes: 223 additions & 0 deletions lib/rules/rule-empty-line-before/README.md
@@ -0,0 +1,223 @@
# rule-empty-line-before

Require or disallow an empty line before rules.

```css
a {}
/* ← */
b {} /* ↑ */
/** ↑
* This line */
```

If the rule is the very first node in a stylesheet then it is ignored.

## Options

`string`: `"always"|"never"|"always-multi-line"|"never-multi-line"`

### `"always"`

There *must always* be an empty line before rules.

The following patterns are considered warnings:

```css
a {} b {}
```

```css
a {}
b {}
```

The following patterns are *not* considered warnings:

```css
a {}

b {}
```

### `"never"`

There *must never* be an empty line before rules.

The following patterns are considered warnings:

```css
a {}

b {}
```

The following patterns are *not* considered warnings:

```css
a {} b {}
```

```css
a {}
b {}
```

### `"always-multi-line"`

There *must always* be an empty line before multi-line rules.

The following patterns are considered warnings:

```css
a
{}
b
{}
```
Copy link
Contributor

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.

Copy link
Member Author

@jeddy3 jeddy3 Feb 1, 2017

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?

Copy link
Member

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.

Copy link
Member Author

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?

Copy link
Member

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.

Copy link
Contributor

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.


The following patterns are *not* considered warnings:

```css
a
{}

b
{}
```

### `"never-multi-line"`

There *must never* be an empty line before multi-line rules.

The following patterns are considered warnings:

```css
a
{}

b
{}
```

The following patterns are *not* considered warnings:

```css
a
{}
b
{}
```

## Optional secondary options

### `except: ["after-single-line-comment", "inside-block-and-after-rule", "first-nested"]`

#### `"after-single-line-comment"`
Copy link
Member

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?

Copy link
Member Author

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.


Reverse the primary option if the rule comes after a single-line comment.

For example, with `"always"`:

The following patterns are considered warnings:

```css
/* comment */

a {}
```

The following patterns are *not* considered warnings:

```css
/* comment */
a {}
```

#### `"inside-block-and-after-rule"`

Reverse the primary option if the rule is inside a block and comes after another rule.

For example, with `"always"`:

The following patterns are considered warnings:

```css
@media {

a {}

b {}
}
```

The following patterns are *not* considered warnings:

```css
@media {
a {}
b {}
}
```

#### `"first-nested"`

Reverse the primary option if the rule is the first in a block.

For example, with `"always"`:

The following patterns are considered warnings:

```css
@media {

a {}

b {}
}
```

The following patterns are *not* considered warnings:

```css
@media {
a {}

b {}
}
```

### `ignore: ["after-comment", "inside-block"]`

#### `"after-comment"`

Ignore rules that come after a comment.

For example, with `"always"`:

The following patterns are *not* considered warnings:

```css
/* comment */
a {}
```

#### `"inside-block"`

Ignore rules that are inside a block.

For example, with `"always"`:

The following patterns are *not* considered warnings:

```css
@media {
a {}
}
```

```css
@media {
a {}
b {}
}
```