Add ignore: [single-declaration] to declaration-block-trailing-semicolon

[Mouvedia]

Which issue, if any, is this issue related to?

Closes #5159

Is there anything in the PR that needs further explanation?

It cannot be named "except" because it would require foo { property: value; } to be valid for "never" which is useless/stupid. Or do you imagine a use case for it that would warrant it?

Should it be supported just for consistency?
Can an option be exclusive to "always"? If so do you have an example?

[jeddy3]

Thanks for the pull request.

Can an option be exclusive to "always"? If so do you have an example?

I can't think of one. If it's exclusive, then we've merged it into primary option. For example, "always-unless-keyword" in font-family-name-quotes.

Primary options and except secondary options avoid inconsistencies. For example: ignore would allow:

@keyframes bugfix { from { padding: 0 } to { padding: 0; } }

The ignore secondary option is usually used when another rule is going to enforce consistency instead, e.g. in a plugin.

Should it be supported just for consistency?

I think we support it for consistency, when catering to your use case.

And, just so I'm clear, you always want trailing semis except (i.e. never) when the declaration block as one declaration regardless of whether the block spans multiple lines?

Like so:

a { background: pink; color: red; }

a {
  background: pink;
  color: red;
}

a { color: red }
a {
  color: red
}

Or do your single declaration blocks always appear within single-line blocks?, e.g.:

a { color: red }

[Mouvedia]

Primary options and except secondary options avoid inconsistencies. For example: ignore would allow:

@keyframes bugfix { from { padding: 0 } to { padding: 0; } }

Good point. Ill fix that.

Or do your single declaration blocks always appear within single-line blocks?

If you check the examples in the README you will see that it works for multi-line blocks as well.
I did it this way just not to complicate things further. Having this granularity may be added at a later time if someone demands it.

I think we support it for consistency, when catering to your use case.

What about { "singleDeclaration": "never" } instead? (ignored/harmless for :[ "never", {)
And if someone insists on having { "singleDeclaration": "always" } for :[ "never", { he will have to create another issue.

[jeddy3]

Thanks for the answers and for updating the pull request.

I'd like to get a clear picture of your use case so that I'm sure we're going down the right path.

Would disallowing trailing semicolons inside single-line blocks cater to your use case, e.g:

a { color: red }
a { background: pink; color: red }

a {
  color: red;
}

This would also apply to the example you gave:

@keyframes bugfix { from { padding: 0 } to { padding: 0 } }

If so, then an except: ["inside-single-line-block"] secondary option, that inverts the primary option, would be consistent with other rules, e.g. declaration-empty-line-before, and, hopefully, easy to implement.

[Mouvedia]

Would disallowing trailing semicolons inside single-line blocks cater to your use case

My personal use-case, would be single-line-block / ignore / for always only. That's not exactly what I have PRd though.

I added the consistent version which always require not having a trailing semicolon as { "singleDeclaration": "never" }.
And complemented it with { "singleDeclaration": "ignore-always" } which allows with and without trailing semicolon for single declarations.

…hopefully, easy to implement.

Like I said I didn't bother with single/multi line blocks for my second PR. It might be easier than I think; Ill have to check.

except: ["inside-single-line-block"]

That would require a { color: red; } to be valid for never which is undesirable/nonsense.

If it's exclusive, then we've merged it into primary option. For example, "always-unless-keyword" in font-family-name-quotes.

"always-unless-single-line-block-with-single-declaration" wouldn't solve my use case because we would still need to have two variants:

• consistent/never
• inconsistent/ignore

I'd like to get a clear picture of your use case

Ignore behaviour is desirable because sometimes you do know that this block may be expanded.
But the consistent case should also be available.

[jeddy3]

Thanks, I think I understand now.

You don't add trailing semicolons when you're sure the block won't expand.

For example, in the case of:

@-webkit-keyframes bugfix { from { padding: 0 } to { padding: 0 } }

In that case, I think an ignore: ["inside-single-line-block"] option is best. Like other ignore options, it'll make the rule more permissive so that idiosyncratic patterns (or those connected to language extensions) can handled by hand or in a plugin.

If there are particular patterns for when a block won't ever be expanded, you can write a plugin to enforce the correct use of the trailing semicolon inside single-line blocks.

[Mouvedia]

I think an ignore: ["inside-single-line-block"] option is best

I am alright with this but how do I convey that it's exclusive to always?
@jeddy3 Or do you want to evaluate a { color: red; } as also valid for :[ "never", { ignore: ["inside-single-line-block"] } ]?

["inside-single-line-block"]

There's another problem: it doesn't convey that it only matches if there's just one declaration.

[jeddy3]

I am alright with this but how do I convey that it's exclusive to always?

It won't be exclusive to always. The rule will simply ignore single-line blocks when this option is used, regardless of the primary option.

@jeddy3 Or do you want to evaluate a { color: red; } as also valid for :[ "never", { ignore: ["inside-single-line-block"] } ]?

Yes, it is also valid.

There's another problem: it doesn't convey that it only matches if there's just one declaration.

It will ignore single-line blocks regardless of how many declarations there are. This will work for your use case, right?

The ignore option is used to make the rule more permissive. Trailing semicolons insde single-line blocks can then be handled by hand or via a plugin (which could take into account the number of declaration etc).

[Mouvedia]

It will ignore single-line blocks regardless of how many declarations there are. This will work for your use case, right?

Actually, it's not. In my experience most of these once-set never-touch block declarations have a single declaration.
That's what I requested.
If it's somehow changed to mean always only for multi-line blocks this is a completely different requests and I am not interested in adding it.

Please check the README and tests and tell me what's wrong with it. I think what Iv come up with is a good compromise—even though it doesn't cater for single or multi line blocks.

[jeddy3]

In my experience most of this once-set never-touch block declarations have a single declaration.

I think your original ignore: ["single-declaration"] will work best then.

Please check the README and tests and tell me what's wrong with it.

To keep the codebase sustainable, we tend to avoid adding code for idiosyncratic patterns. Instead, we add ignore options so that certain patterns are ignored by the built-in rules, and can then be checked by a complementary plugin, e.g. as how the stylelint-scss plugin does it.

[Mouvedia]

I think your original ignore: ["single-declaration"] will work best then.

@jeddy3 done.

[jeddy3]

@Mouvedia Thanks for reverting to the ignore option. The code looks good.

I've requested some minor changes to the docs and tests to align them with our conventions and to be consistent with the rule's other examples and tests. The conventions help:

• us maintain the test code
• users when looking through lots of rules

[jeddy3]

Thanks! LGTM.

[ybiquitous]

I've left minor comments about the document, but this PR looks good to me. 👍