Add media-feature-name-value-whitelist

[MatthiasKunnen]

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

Closes #3312

Is there anything in the PR that needs further explanation?

No, it's self explanatory.

[alexander-akait]

Thanks for work 👍 Can you add tests to avoid non standard syntax problem (you can look on this in other same rules)?

[MatthiasKunnen]

@evilebottnawi, there are two tests for non standard syntax. SCSS in particular. What kind of additional tests do you have in mind?

[alexander-akait]

@stylelint/contributors we ignore non standard syntax in any places right?

[MatthiasKunnen]

Correct

[MatthiasKunnen]

Non standard syntax is handled as suggested in the issue (#3312 (comment)) by @hudochenkov.

[alexander-akait]

/cc @hudochenkov we do same for same rules?

[jeddy3]

@MatthiasKunnen Thanks for this! It's looking great.

I've made a few minor requests.

(Sorry about the delay reviewing this. I've been out the country for a couple of weeks.)

---

Non standard syntax is handled as suggested in the issue (#3312 (comment)) by @hudochenkov.

@evilebottnawi /cc @hudochenkov we do same for same rules?

I believe this rule is behaving consistently to other whitelist and blacklist rules.

[jeddy3]

A minor tweak, as I believe the "name" and the "value" represent the pair.

Specify a whitelist of allowed media feature name and value pairs.

[jeddy3]

Specify a whitelist of allowed media feature name and value pairs.

[jeddy3]

Please align the arrows with the start of each bit of vocab i.e. the "m" in "min-width" and "7" in "768px"

(There are a lot of rules in stylelint, so we try to be consistent as possible across all the docs).

[MatthiasKunnen]

Will do. I've not come across this in the docs so I wasn't aware of this rule.

[jeddy3]

Yep, it's not an obvious one to glean. I've created a PR to explicitly highlight the convention (along with the "This rule ..." one).

[jeddy3]

Please write as the following to be consistent with most of the other rules:

"This rule ignores media features within range or boolean context."

I'll create a separate issue about updating the other rules that still use the old "Caveat:" convention (e.g. media-feature-name-blacklist).

[MatthiasKunnen]

Yeah, I reused some things here and there to the rule as consistent as possible. That the caveat was deprecated, I did not know :)

[jeddy3]

Yeah, I reused some things here and there to the rule as consistent as possible.

Yep, I saw. Good job and thanks :)

That the caveat was deprecated, I did not know :)

We're still ironing out all the kinks in the docs, which is why your kind of feedback is so useful.

We just merged a PR to make the other rule READMEs consistent.

[jeddy3]

Let's go with the following to be more consistent with declaration-property-value-whitelist:

---

Options

object: { "unprefixed-media-feature-name": ["array", "of", "values"] }

If a media feature name is found in the object, only its whitelisted values are allowed. If the media feature name is not included in the object, anything goes.

If a name or value is surrounded with / (e.g. "/width$/"), it is interpreted as a regular expression. For example, /width$/ will match max-width and min-width.

---

[MatthiasKunnen]

Is this the only rule that uses object:? I personally find it atrocious to look at/read in code as well as rendered. The JSON object is better formatted.

{
  "max-width": ["Array", "of", "values"],
  "/regex/": ["/regex/", "non-regex"]
}

I believe there is another rule that uses this in some form but I'd have to check.

[jeddy3]

I believe there is another rule that uses this in some form but I'd have to check.

I think it's only the declaration-property-*-*list rules that accept objects. I might be wrong, though.

I personally find it atrocious to look at/read in code as well as rendered.

Yep, I was thinking the same thing. However, if we can't find another example of it done as a JSON object then I suggest we go with the other approach in this PR to keep things consistent.

We should then create a separate issue to address how we can better communicate the options across the board. To be honest, all the option descriptions need a little love and I don't think we ever rationalised the approach we took. It'd be good to look, as part of that issue, into how other tools communicate their options.

[jeddy3]

Remove this title, please.

[jeddy3]

"Given:"

(It's a little clunky, but the stylelint website needs the semicolon for the pattern background colours).

[jeddy3]

I think two values here would be useful to the reader e.g. "min-width": ["768px", "1024px"].

You'll need to add an additional pattern to the "not considered violations" list for it.

[jeddy3]

Can we get this two lines please to test the line property value e.g.

code: "@media screen (min-width: 768px)\nand (min-width: 1000px) {}",`
description: "Media feature multiple",
message: messages.rejected("min-width", "1000px"),
line: 2,
column: 5

[MatthiasKunnen]

You mean at column 17, right? The rule reports errors on the value, not the media feature name.

[jeddy3]

You mean at column 17, right?

Oops, yes.

[jeddy3]

Formatters will usually append the rule name, therefore the "media feature" bit is a little redundant. Let's go with the following instead:

const messages = ruleMessages(ruleName, {
  rejected: (name, value) =>
    `Unexpected value "${value}" for name "${name}"`
});

[MatthiasKunnen]

@jeddy3, thank you for the review. I've replied on some of your requested changes and will push updates soon.

@evilebottnawi, you've requested changes but that seems to be out-of-date.

[jeddy3]

@MatthiasKunnen Changes look good!

I think once the line test is in and the options section is changed to:

---

Options

object: { "unprefixed-media-feature-name": ["array", "of", "values"] }

If a media feature name is found in the object, only its whitelisted values are allowed. If the media feature name is not included in the object, anything goes.

If a name or value is surrounded with / (e.g. "/width$/"), it is interpreted as a regular expression. For example, /width$/ will match max-width and min-width.

---

We'll be good to merge and get this into 9.3.0

[MatthiasKunnen]

@jeddy3, the line test is already added. I suggest to resolve #3372 first. I already have a PR ready but I am holding on to it until my last comment has been addressed.

[MatthiasKunnen]

@jeddy3, this PR is ready I believe. The new options format in the README depends on PR #3389.

[jeddy3]

@MatthiasKunnen Thanks for making all the changes.

Excellent work. I'll merge this as-is, as #3372 has grown in scope and it'd be great to get this new rule into 9.3.

[jeddy3]

• Added: media-feature-name-value-whitelist rule (#3320).